Public/private dual card system and method

ABSTRACT

A system and method for providing a multiple-service card is disclosed. A card member  108  is provided with a single card that serves as both an open transaction instrument and a private retailer transaction instrument. This multiple-service card may have the traditional credit card data on one side of the card, including, for example, the account number, name of the account holder, and the expiration date. The other side of the card may include a magnetic stripe that contains the account information in machine readable form as well as private retailer transaction instrument information. In the system, the primary party and the service partner participants cooperate to complete the processes associated with the provision of the combined card services, including a new account process, card replacement and renewal processes, a service partner cancellation process, and a process for cancellation and/or transfer by a primary party.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a Reissue of U.S. Ser. No. 10/709,815 (filed May 28,2004), (issued as U.S. Pat. No. 7,172,112 on Feb. 6, 2007). U.S. Ser.No. 10/709,815 This application is a continuation-in-part of, and claimspriority to, U.S. patent application Ser. No. 09/764,688, filed on Jan.16, 2001, by Inventors Fitzmaurice et al., and entitled“MULTIPLE-SERVICE CARD SYSTEM”, now U.S. Pat. No. 6,742,704, whichitself claims priority to U.S. Provisional Patent Application No.60/177,530, filed Jan. 21, 2000; and 2000. U.S. Ser. No. 10/709,815 isalso a continuation-in-part of U.S. patent application Ser. No.10/708,585, filed on Mar. 12, 2004 now U.S. Pat. No. 7,268,668, byinventors Beenau et al., and entitled “SYSTEMS AND METHODS FOR MANAGINGMULITPLE ACCOUNTS ON A RF TRANACTION INSTRUMENT”, which itself claimspriority to INSTRUMENT.” U.S. Ser. No. 10/708,585 is acontinuation-in-part of U.S. patent application Ser. No. 10/608,792,entitled “METHOD AND APPARUTUS FOR ENROLLING WITH MULTIPLE TRANSACTIONENVIRONMENTS,” filed Jun. 27, 2003, and 2003. U.S. Ser. No. 10/708,585is also a continuation-in-part of U.S. patent application Ser. No.10/435,420, entitled “SYSTEM AND METHOD FOR MANAGING ACCOUNT INFORMATIONLIFE CYCLES,” filed May 9, 2003, all 2003. All of which the above arehereby incorporated by reference.

FIELD OF INVENTION

The present invention generally relates to private retail transactioncard and open transaction card services and, more particularly, to asystem and method for providing a single card that functions as both aprivate retail transaction card and open transaction card and a systemand method for facilitating the management of multiple data sets onvarious card and “non-card” transaction enabling instruments.

BACKGROUND OF INVENTION

In today's world, there is a wide variety of benefits that are availableto a consumer where access to the benefits depends upon the consumer'spossession of a card. For example, some of the benefits, to which atypical consumer may gain access by possessing a card, include proof ofidentity, proof of professional licensing, entry to an exclusivemembership club, entry to an access-restricted location, access tocredit services, telephone system use, and accrual of loyaltyrewards/incentives such as frequent flier miles or grocery storediscounts and rebates. For example, U.S. Pat. No. 5,924,080, which ishereby incorporated by reference, discloses a system that may enable aconsumer to receive discounts without the burden of using coupons,similar to the system currently used by many grocery stores.

Due to the desirability of such benefits, consumers in today's worldtypically carry a wide array of cards in their wallets and purses. Thecards consumers now carry include, among others, credit cards, driver'slicenses, club membership cards, frequent flier cards, professionalregistration cards, retailer loyalty cards, and security-relatedrestricted-access cards. Typically, each of these consumer cardscontains information about the specific user or consumer, informationabout the service or benefit provider and information serving to definethe benefits or services, to which the consumer is entitled by virtue ofhis or her possession of the card. The information concerning the cardmember may include photographs, signatures, fingerprints, and otherinformation that identifies or describes the card member. Informationregarding the identity of the service provider and the associatedbenefits, to which the card member is entitled, may be readilyascertained by reading the face of the card, may be encoded or accessedby using the card. Information may be incorporated onto the cardsthrough a variety of means including imprinting, punching, laminating,embossing, bar encoding, magnetic stripe encoding, and even affixationor incorporation of micro-chips. For example, U.S. Pat. No. 4,998,753,which is hereby incorporated by reference, discloses a driver's licenseformed as a plastic card.

Unfortunately, due to the proliferation of services and benefitscurrently available from diverse service providers, the quantity ofcards that average consumers carry has become unreasonably andunnecessarily burdensome. For example, on a single shopping trip, atypical consumer may carry a drivers license to drive their motorvehicle to the merchant's location, a membership card to obtain accessto the merchant's exclusive membership club, a calling card to makephone calls during the shopping trip, and a credit card to obtain creditservices to facilitate the purchase of goods from the merchant. Yet, itcan be cumbersome and uncomfortable to carry all these necessary cardsin one's wallet, pocket or purse.

Thus, it would be advantageous to decrease the volume of cards that aconsumer must carry while retaining the consumer's access to the fullarray of benefits provided by the diversity of service providers. U.S.Pat. No. 5,590,038, which is hereby incorporated by reference, disclosesa universal electronic transaction card that may serve as a credit card,identification card, and medical card. Further, U.S. Pat. No. 5,844,230,which is also hereby incorporated by reference, discloses a card thatmay contain the information of two credit cards on a single card. Whilethese references attempt to decrease the volume of cards a consumer mustcarry to access a given set of services, they require, among otherelements, multiple sets of embossed information and multiple magneticstripes.

Simultaneous with this desire to reduce the volume of cards, there is anevident need to increase the information carrying capacity of suchconsumer cards. For example, U.S. Pat. No. 5,308,121 and a relatedpatent, U.S. Pat. No. 5,503,434, both of which are hereby incorporatedby reference, disclose credit cards that can be unfolded to allow moreroom for the printing of information. Furthermore, U.S. Pat. No.4,066,873, which is also hereby incorporated by reference, discloses abanking identification and access card that contains a magnetic stripeand a bar code on the back of the card that can be scanned by a scanningapparatus.

Yet, despite these varied efforts at increasing the utility of consumercards while decreasing the volume of cards a consumer must carry, nocard currently exists that offers the combined benefits of multiplecards without necessitating the incorporation of additional embossedinformation or magnetic stripes on the associated card. Furthermore, theprior art attempts at reducing the quantity of cards a consumer mustcarry are typically aimed at modifying the cards, rather than modifyingthe processes and systems employed by the individual benefit providers,such that the consumer may continue to enjoy benefit from multipleproviders. In fact, none of the methods or systems for providing amultiplicity of services through a single card that are known in the artinvolve substantial administrative cooperation between distinct serviceproviders.

Furthermore, it has become apparent that consumers who seek access to aparticular set of benefits from one service provider are more likely todesire access to a second set of benefits from a distinct class ofservice providers. For example, it stands to reason that consumers whoaccess a membership shopping club are likely to desire credit servicesduring their trip to the club. Therefore, it would be advantageous forproviders of distinct services such as credit services and membershipclub shopping services to cooperate to offer a single card that providesconsumers with access to the benefits of the currently separate anddistinct cards. By doing so, a primary party provider of credit servicesand a partnering membership club can encourage use of their respectiveservices while providing a synergistic administrative benefit tothemselves and their consumers.

Moreover, the separate cards currently carried by a typical consumercontain a multiplicity of duplicate information such as pictures,signatures, addresses, billing information, etc. Therefore, it would beadvantageous to minimize duplication of identical information onmultiple cards. It would further be advantageous for the information tobe grouped on the different sides of a single card such that a firstside of the card provides a first set of benefits while the other sideof the card provides access to a separate and distinct set of benefits.Thus, it would be advantageous to have a multiple-service card thatfunctions to provide a consumer with the benefits typically provided bydistinct service providers. It would further be advantageous if themultiple-service card did not require multiple card-like elementsconnected by a hinge or the use of multiple magnetic stripes. It wouldfurther be advantageous to have a system and method to facilitatecooperation between separate and distinct providers of card services.

Further, it would be advantageous to have a multiple-service card thatfunctions as both a credit card as well as a separate entity'smembership card. It would also be advantageous for the multiple-servicecard to feature the customer's picture on the card's back side, ratherthan on its front side. It would also be advantageous to have thepicture that is to be placed on the back of the card captured by theservice partner and passed to the card generator. It would also beadvantageous to have a card that contains a bar code that may be scannedat the point of sale when customers make purchases so that the scanneddata may be forwarded directly to the service partner's systems forreporting and tracking purposes.

Some financial transaction instruments, such as credit cards and loyaltyprogram cards, are capable of accessing information related to multipleaccounts. For example, a credit card may be able to access membershipdata associated with both a credit card account and a wholesale purchaseclub account. These financial transaction instruments may generallyinclude one or more applications for selecting and then securelyutilizing a sub-set of specified account information. However, thesystems associated with these cards typically delegate the loading ofthese applications and management of the related data sets to thirdparties on behalf of both the issuer of the instrument and “applicationtenants” residing on the issuer's financial transaction instruments.Managing data associated with a credit card via the issuer/third partymay involve time consuming steps such as requesting permission to managedata, conforming to data standard formats, and implementing changes.Thus, traditional solutions for managing multiple application tenantsare disadvantageous in that the traditional solutions leave adisproportional burden on the issuer and/or the delegated third party interms of managing accounts on a financial transaction instrument.

Another disadvantage is that, in general, the financial transactioninstruments, which are capable of accessing information related tomultiple accounts, are typically designed to access only those multipleaccounts managed by the same issuer. For example, the same issuerprovides both the credit card and the wholesale purchase club account tothe user. As such, the issuer providing both accounts generallyestablishes its own application tenant storage format and managementprotocol related to the accounts. The established format and protocol isordinarily different from any format or protocol used by other unrelatedissuers, which provides the issuer increased control over access to theaccount data. Because of the differing unique protocols/formats amongstissuers, multiple issuers typically provide a transaction instrumentcorresponding to an account offered by the issuer, where the data foraccessing the account is stored in that issuer's protocol/format. Thus,a user wishing to access multiple accounts managed by different issuers,must ordinarily carry at least one transaction instrument per issuer.Carrying multiple transaction instruments can be inconvenient in thatthe instruments may be more easily misplaced, lost or stolen, preventingthe user from accessing the account.

Another disadvantage of the above conventional methods of managingmultiple accounts, which is related to the different issuerformats/protocols, is that, since conventional financial transactioninstruments typically only store application tenant information relatedto one issuer, the information may not be recognized by a second issuerdistinct from the first. That is, the user of the financial transactioninstrument typically is only able to use the financial transactioninstrument at locations identified by the issuer of the transactioncard. The financial transaction instrument may not be used at any otherlocations, since the locations not identified by the user will notrecognize the application tenant information which is typically storedon the instrument in a issuer determined format. As such, in order toaccess multiple accounts managed by different issuers using differentformats/protocols, the user must typically carry multiple cards, asnoted above.

In addition to the above, the conventional multiple account managementsystems have another disadvantage in that data contained on thefinancial transaction instruments may not be easily updated. That is,traditional financial transaction instruments are only “readable”instruments, and not “writeable” instruments, where the data on theinstrument may be read from the instrument but not written to theinstrument. More particularly, once the financial instrument is issuedto the user, the data often may not be modified. Instead, whereinformation contained on the instrument is to be modified, a newphysical consumer device (e.g. transaction instrument) often needs to beissued. That is, the information stored on the financial transactioninstruments are typically not permitted to be changed without issuerinvolvement. The issuer may be involved, for example, by verifyingcompatibility of a proposed new or updated information, checkingconformance of the data to the issuer's standard formatting and sizeguidelines, and implementing the changes. Thus, additional burdens areplaced on the issuer where it is necessary to add unique data sets to afinancial transaction instrument, or to update the data stored thereon.

As such, the ability to store data on a single financial transactioninstrument thereby permitting a user of the single instrument tocomplete transactions using multiple transaction accounts issued bydifferent distinct issuers, does not exist. A need exists for a singlefinancial transaction instrument which stores multiple independent datasets provided by multiple distinct issuers irrespective of theformat/protocol of the various issuers. A need further exists for asingle financial transaction instrument which may be used to efficientlymanage the data sets and applications stored on the instrument,irrespective of the protocol used by an issuer to process the data. Evenmore particularly, a need exists for a system for managing multipletransaction accounts of differing formats on a single financialtransaction instrument which is issued to a user, and which permits theuser to access different accounts provided by multiple distinctfinancial account issuers.

SUMMARY OF INVENTION

The present invention provides a system and method for providingconsumers with the benefits of multiple cards while allowing consumersto carry a single card. To accomplish this advantage, the system andmethod of the present invention enables a single card to function inmultiple modes, for example, as both a private retail transaction cardmanaged by a service partner and an open transaction card. By providinga system of back-end functionality that takes advantage of cooperationbetween the multiple service providers, the present invention reducesthe disadvantages of the prior art systems such as, for example, therequirement to join, through use of a hinge and a fastener, multiplecard segments or the requirement to embed multiple magnetic stripes intothe consumer's card.

More particularly, the system of the present invention provides methodsfor opening new accounts, methods for accomplishing card replacement,methods for canceling a service partner membership, methods forcanceling a primary party account, and methods for transferring anaccount to a different service partner account. The multiple-servicecard enabled by the present invention may include any combination ofmembership information, a barcode, and a photo in addition to standardcredit card information.

In one exemplary embodiment of the present invention, a system andmethod is provided for facilitating the management of distinct data setsof different formats on a RF operable transaction instrument. The systemincludes a RF financial transaction instrument for use in managingmultiple distinct data sets provided by distinct issuers. The methodincludes the steps of: receiving, from a read/write device, at least afirst data of a first format at the financial transaction instrument,wherein the first data set is owned by a first owner; receiving, fromthe read/write device, at least a second data set of a second format atthe financial transaction instrument, wherein the second data set isowned by a second owner, and wherein the first format is different fromthe second format; storing the first data set and the second data set onthe financial transaction instrument, in distinct fashion and inaccordance with the first and second format respectively, where thefirst data set and the second data set are unique one from the other;and modifying (e.g., adding, deleting, overwriting, altering) at leastthe first data set, and/or adding a third data set, in accordance withinstructions provided by the data set owner or user.

In another example, a financial transaction instrument comprises a dataset management system for facilitating the management of more than onedata set stored on the transaction instrument, the RF financialtransaction instrument comprising at least one data storage areaconfigured to store a first data set of a first format and a second dataset of a second format different from the first format. The first dataset is associated with a first data set owner (e.g., first issuer) andthe first data set is configured to be stored on the financialtransaction instrument independent of a second data set owner (e.g.,second issuer); and, the second data set is associated with the secondowner and the second data set is configured to be stored on thefinancial transaction instrument independent of the first data setowner, wherein the first data set and the second data set are stored inaccordance with the first and second format, respectively.

In yet another exemplary embodiment of the present invention, a datamanagement system comprises: a RF financial transaction instrumentassociated with a first data set of a first format and a second data setof a second format, wherein the financial transaction instrument isconfigured to facilitate management of the first data set withoutinvolvement of the first data set owner. The data management system mayfurther comprise a read/write device configured to communicate with thefinancial transaction instrument for providing the first and second datasets to the instrument and for modifying the data sets thereon inaccordance with a condition header annotated to the data sets. Theread/write device may be stand alone, or the device may be connected toa transaction processing network. The read/write device may be used toload the issuer-owned data onto the transaction instrument, andthereafter delete, augment and/or manage the information stored thereon,or to add additional distinct data sets.

As noted, exemplary embodiments of the financial transaction instrumentof the present invention may include storing a first and second data setof differing formats on a transaction instrument database. Alternateexemplary embodiments of the present invention may also include a“mirror image” of the first and second data set stored on a remotedatabase removed from the transaction instrument issuer and thetransaction instrument itself. The remote database may be placed incommunication with the transaction instrument issuer system, and thefinancial transaction instrument via, for example, electroniccommunication with a network. As such, in one exemplary aspect, thepresent invention permits changes which are made on the remote database(or transaction instrument) to be mimicked or synchronized on theinstrument (or remote database).

In still another exemplary embodiment, the invention securesauthorization from an issuer prior to loading the issuer-owned data ontothe RF transaction instrument. Once authorization is given, the issuermay be “enrolled” in a transaction instrument multiple accountmanagement system, the associated issuer-owned data may then be loadedon the transaction instrument. The issuer-owned data may be loaded in aformat recognizable by a merchant system or by a system maintained byissuer. Thus, when the transaction instrument is presented to complete atransaction, the data may be transferred to the issuer in an issuerrecognized format, eliminating the need to carry multiple transactioninstruments for each issuer. That is, the issuer receives the data in anissuer recognized format and may process the accompanying transactionunder issuer's already established business as usual protocols. In thisway, the issuer is permitted to manage its issuer provided program atthe issuer location, irrespective of the management of other programsprovided by other distinct issuers enrolled in the multiple accountmanagement system.

BRIEF DESCRIPTION OF DRAWINGS

Additional aspects of the present invention will become evident uponreviewing the none-limiting embodiments described in the specificationand the claims taken in conjunction with the accompanying figures,wherein like numerals designate like elements, and:

FIG. 1 is a schematic diagram of an exemplary system for providing amultiple-service card;

FIG. 2a is a flowchart of a portion of an exemplary new account process,complementing FIG. 2b, in accordance with the present invention;

FIG. 2b is a flowchart of a portion of an exemplary new account process,complementing FIG. 2a, in accordance with the present invention;

FIG. 3a is a flowchart of a portion of an exemplary multiple-servicecard replacement process, complementing FIG. 3b, in accordance with thepresent invention;

FIG. 3b is a flowchart of a portion of an exemplary multiple-servicecard replacement process, complementing FIG. 3a, in accordance with thepresent invention;

FIG. 4 is a flowchart of an exemplary multiple-service card servicepartner membership cancellation process in accordance with the presentinvention;

FIG. 5a is a flowchart of a portion of an exemplary multiple-servicecard primary party cancellation process, complementing FIG. 5b, inaccordance with the present invention;

FIG. 5b is a flowchart of a portion of an exemplary multiple-servicecard primary party cancellation process, complementing FIG. 5a, inaccordance with the present invention;

FIG. 6 illustrates a general overview of an exemplary data setmanagement method in accordance with an exemplary embodiment of thepresent invention;

FIG. 7 illustrates a block diagram overview of an exemplary data setmanagement system in accordance with an exemplary embodiment of thepresent invention;

FIG. 8 illustrates a more detailed exemplary data set management methodin accordance with an exemplary embodiment of the present invention;

FIG. 9 illustrates an exemplary data set management method for addingdata sets in accordance with an exemplary embodiment of the presentinvention;

FIG. 10 illustrates an exemplary data set management method for deletingdata sets in accordance with an exemplary embodiment of the presentinvention;

FIG. 11 illustrates an exemplary method for userself-management of datasets in accordance with an exemplary embodiment of the presentinvention;

FIG. 12 illustrates an exemplary method for issuer management of datasets in accordance with the present invention; and

FIG. 13 illustrates an exemplary data set selection method for use incompleting a transaction.

DETAILED DESCRIPTION

The present invention may be described herein in terms of functionalblock components, screen shots, optional selections, and variousprocessing steps. It should be appreciated that such functional blocksmay be realized by any number of hardware and/or software componentsconfigured to perform the specified functions. For example, the presentinvention may employ various integrated circuit components, e.g., memoryelements, processing elements, logic elements, look-up tables, and thelike, which may carry out a variety of functions under the control ofone or more microprocessors or other control devices. Similarly, thesoftware elements of the present invention may be implemented with anyprogramming or scripting language such as C, C++, Java, COBOL,assembler, PERL, or the like, with the various algorithms beingimplemented with any combination of data structures, objects, processes,routines or other programming elements. Further, it should be noted thatthe present invention may employ any number of conventional techniquesfor data transmission, signaling, data processing, network control, andthe like. For a basic introduction to cryptography, please review a textwritten by Bruce Schneider, which text is entitled “AppliedCryptography: Protocols, Algorithms, And Source Code In C,” published byJohn Wiley & Sons (second edition, 1996), which is hereby incorporatedby reference.

It should be appreciated that the particular implementations shown anddescribed herein are illustrative of the invention and its best mode andare not intended to otherwise limit the scope of the present inventionin any way. Indeed, for the sake of brevity, conventional datanetworking, application development, and other functional aspects of thesystems (and components of the individual operating components of thesystems) may not be described in detail herein. Furthermore, theconnecting lines shown in the various figures contained herein areintended to represent exemplary functional relationships and/or physicalcouplings between the various elements. It should be noted that manyalternative or additional functional relationships or physicalconnections may be present in a practical electronic transaction system.It should further be noted that the order of the steps denoted in theattached drawings are not intended as limitations and the steps may beaccomplished in other orders without deviating from the scope of thepresent invention. Still further, the actors denoted as performingindividual steps in the disclosed process should not be interpreted aslimiting in any way as one with ordinary skill in the art appreciatesthat the steps may be performed by actors different from those disclosedherein without deviating from the spirit and scope of the presentinvention.

It will be appreciated that many applications of the present inventioncould be formulated. One skilled in the art will appreciate that thenetwork may include any system for exchanging data or transactingbusiness, such as the Internet, an intranet, an extranet, WAN, LAN,satellite communications, and/or the like. The parties may interact withthe system via any input device such as a keyboard, mouse, kiosk,personal digital assistant, handheld computer (e.g., Palm Pilot®),cellular phone, and/or the like. Similarly, the invention could be usedin conjunction with any type of personal computer, network computer,workstation, mini-computer, mainframe, or the like running any operatingsystem such as any version of Windows, Windows NT, Windows 2000, Windows98, Windows 95, MacOS, OS/2, BeOS, Linux, UNIX, or the like. Moreover,although the invention may be implemented with TCP/IP communicationsprotocols, it will be readily understood that the invention could alsobe implemented using IPX, Appletalk, IP-6, NetBIOS, OSI, or any numberof existing or future protocols. Moreover, the system contemplates theuse, sale, or distribution of any goods, services, or information overany network having similar functionality described herein.

The consumer, merchant, primary party, and service partner may representindividual people, entities, or businesses. Although labeled as a“primary party,” the primary party may represent other types oftransaction instrument issuing institutions, such as credit cardcompanies, card sponsoring companies, loyalty/incentive companies orthird party issuers under contract with financial institutions. Theprimary party, in one embodiment, may be the first data set owner asdiscussed herein. The primary party may also provide an open transactioninstrument which may be utilized in a payment network. The paymentnetwork which may be part of certain transactions represents existingproprietary networks that presently accommodate transactions for creditcards, debit cards, and other types of financial/banking cards. Thepayment networks may include or be operated by, for example, AmericanExpress®, VisaNet® and the Veriphone® networks. The payment network maystill be considered a “closed” network in that is assumed to be securefrom eavesdroppers, but the transaction instruments shall still bereferred to herein as “open” transaction instruments to differentiatethe instruments from the “private retail” or “closed” transactioninstrument. The open transaction instrument, as used herein, may includeany transaction instrument or card (or other transaction account ordevice discussed herein) which may be used at different merchants. It isfurther noted that other participants may be involved in some phases ofthe system and methods, but these participants are not shown.

The service partner may include a private retailer which may issue itsown private retail or closed transaction instrument which may only beaccepted at the particular retailer, the retailer's affiliates and/or asubset of retailers. The private retail transaction instrument may beused on the open payment networks discussed above or on a privatepayment network. The private retail transaction instrument may include,for example, the Macy's® charge card, Sears® charge card, etc. Theprivate retailer may be the second data set owner as described herein.

As illustrated in FIG. 1, in an exemplary embodiment, the system of theinstant invention may comprise a primary party 102 provider of creditservices as well as a service partner 106. Both the primary party 102and the service partner 106 are equipped with a computing unit or systemto facilitate online commerce transactions and communications. Thesecomputing units or systems may take the form of a computer or set ofcomputers, although other types of computing units or systems may beused, including laptops, notebooks, hand held computers, set-top boxes,workstations, computer-servers, main frame computers, mini-computers, PCservers, network sets of computers, and/or the like.

The primary party 102 and the service partner 106 both comprisecomputing units or systems, which communicate with and through a cardservice engine 104, and all of which are connected with each other via adata communication network. The network may be a public network, whichshould be assumed to be insecure and open to eavesdroppers. For example,the internet may be employed as the network. In this context, thecomputers may or may not be connected to the Internet at all times. Forinstance, the service partner 106 computer may employ a modem tooccasionally connect to the Internet, whereas the primary party'scomputing center might maintain a permanent connection to the Internet.It is noted that the network may also be implemented as other types ofnetworks, such as an interactive television (ITV) network. The computersmay also be interconnected via existing proprietary networks such asthose that presently accommodate transactions for credit cards, debitcards, and other types of financial/banking cards. Such aninterconnection is a closed network that may be assumed to be securefrom eavesdroppers. Examples of these proprietary networks include theAmerican Express®, VisaNet®, and the Veriphone® networks.

As will be appreciated by one of ordinary skill in the art, the presentinvention may be embodied as a method, a data processing system, adevice for data processing, and/or a computer program product.Accordingly, the present invention may take the form of an entirelysoftware embodiment, an entirely hardware embodiment, or an embodimentcombining aspects of both software and hardware. Furthermore, thepresent invention may take the form of a computer program product on acomputer-readable storage medium having computer-readable program codemeans embodied in the storage medium. Any suitable computer-readablestorage medium may be utilized, including hard disks, CD-ROM, opticalstorage devices, magnetic storage devices, and/or the like.

The present invention is described below with reference to blockdiagrams and flowchart illustrations of methods, apparatus (e.g.,systems,) and computer program products according to various aspects ofthe invention. It will be understood that each functional block of theblock diagrams and the flowchart illustrations, and combinations offunctional blocks in the block diagrams and flowchart illustrations,respectively, can be implemented by computer program instructions. Thesecomputer program instructions may be loaded onto a general purposecomputer, special purpose computer, or other programmable dataprocessing apparatus to produce a machine, such that the instructions,which execute on the computer or other programmable data processingapparatus, create means for implementing the functions specified in theflowchart block or blocks.

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction means,which implement the function specified in the flowchart block or blocks.The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer-implemented process such that theinstructions, which execute on the computer or other programmableapparatus, provide steps for implementing the functions specified in theflowchart block or blocks.

Accordingly, functional blocks of the block diagrams and flowchartillustrations support combinations of means for performing the specifiedfunctions, combinations of steps for performing the specified functions,and program instruction means for performing the specified functions. Itwill also be understood that each functional block of the block diagramsand flowchart illustrations, and combinations of functional blocks inthe block diagrams and flowchart illustrations, can be implemented byeither special purpose hardware-based computer systems, which performthe specified functions or steps, or suitable combinations of specialpurpose hardware and computer instructions.

Further, as one skilled in the art will appreciate, a “consumer card” or“credit card”, as used herein, includes any device, code, or suitablefinancial instrument. The device, code or instrument may also representan account with a financial institution, such as a bank, a card issuer,and/or the like. The device, code, or other suitable financialinstrument may also have a credit line or balance associated with it,wherein the credit line or balance is in a form of a financial tenderhaving discrete units, such as currency. Moreover, a “consumer card” or“credit card”, as used herein, includes any device, code, or financialinstrument suitably configured to allow the cardholder to interact orcommunicate with the system, such as, for example, a charge card, creditcard, debit card, prepaid card, telephone card, smart card, magneticstripe card, bar code card, authorization/access code, personalidentification number (PIN), Internet code, other identification code,and/or the like. Additionally, a “cardholder” or “card member” includesany person or entity that uses a consumer card and participates in thepresent system and may include a person who is simply in possession of afinancial account identifier, such as an authorization or account code.

Communication between the parties to the system of the present inventionis accomplished through any suitable communication means, such as, forexample, a telephone network, Intranet, Internet, point of interactiondevice (point of sale device, personal digital assistant, cellularphone, kiosk, etc.), online communications, off-line communications,wireless communications, and/or the like. One skilled in the art willalso appreciate that, for security reasons, any databases, systems, orcomponents of the present invention may consist of any combination ofdatabases or components at a single location or at multiple locations,wherein each database or system includes any of various suitablesecurity features, such as firewalls, access codes, encryption,de-encryption, compression, decompression, and/or the like.

In general, in an exemplary embodiment, the multiple-service card is acredit card co-branded with a service partner membership card. Aprospective card member 108 provides the service partner 106 withapplication information for both the primary party's services and aservice partner's services. Such information may include, for example,traditional credit card application information as well as traditionalmembership club application information. The service partner 106collects and processes the application information, and forwards it tothe primary party 102, via the card service engine 104, for furtherprocessing. The card service engine 104 approves or declines the newaccount, and returns the information to the service partner 106. Theservice partner 106, then, matches the approved accounts with themembership applications it has previously processed. Finally, theservice partner 106 sends its membership information to a card generator120, which fabricates the physical card and sends the card to the cardmember 108. An example of the card fabrication process is found in U.S.patent application Ser. No. 09/653,837, entitled “Transaction Card”,filed Sep. 1, 2000, the entire contents of which are herein incorporatedby reference.

As a result, a card member 108 may be provided with a single card thatserves as both a credit card and a club membership card for access tothe service partner's pen or exclusive club. This multiple-service cardmay have the traditional credit card data on one side of the card,including, for example, the account number, name of the account holder,and the expiration date. The other side of the card may include amagnetic stripe that contains the account information in machinereadable form, a space for a signature, a customer service number, aservice partner membership number that is suitable to permit entry intoa service partner's facility, a barcode with the same membershipinformation and that may be scanned at the point of sale, and aphotograph or a digital image or another identifying image of the cardholder. The photograph or other identifying image may be taken at theservice partner's location. Any combinations of the foregoing data maybe located on either side of the card.

In the system of the instant invention, the primary party 102 and theservice partner 106 participants cooperate to complete the processesassociated with the provision of the combined card services. Thoseprocesses may include a new account process, card replacement andrenewal processes, a service partner membership cancellation process,and a process for cancellation and/or transfer by a primary party 102.The card replacement and renewal process may be initiated by the primaryparty 102 or the service partner 106 and may be a response to a member'srequest, a member's reporting of fraudulent activity, an emergency, orthe member's activity in association with a service partner 106. Each ofthe process participants performs a series of process steps.

As used herein, the term product control number refers to a number thatidentifies the service partner 106 that keyed in the application and thedate on which it was keyed. Also, as used herein, the term balancingreport refers to a report that verifies and files information sentbetween two parties. Finally, the information administrator 112 recordsinformation, transfers files, and send reports and other electroniccommunication between the primary party 102 and a service partner 106.

In The New Account Process. In an exemplary new account process,multiple process participants cooperate to accomplish the process steps.The process participants may include only the primary party 102, thecard service engine 104, and the service partner 106, but thoseparticipants may also delegate their responsibilities to entities withintheir respective organizations or to other entities. Furthermore, thecard service engine 104 may be the same party as either the primaryparty 102 or the service partner 106. Referring to FIGS. 2a and 2b,regardless whether, or to which entities, the various process steps aredelegated, the new account process is initiated by a card member'ssubmission of application information (step 210) to either the servicepartner 106 or the primary party 102. If the card member 108 submits theinformation to the service partner 106, the service partner 106 performsthe initial processing of the application information (step 220). If thecard member 108 submits the application information to the card serviceengine 104, however, the primary party 102 receives the application(step 210) from the card member 108 and routs (step 210) the informationto the service partner 106, which performs the initial processing (step220).

The initial processing (step 220) performed by the service partner 106includes the steps of receiving (step 221) the application information,keying (step 222) each application information file for basicinformation, transferring (step 223) the application information intothe service partner's database, creating (step 224) a unique applicationinformation file product control number for each application, creating(step 225) a standard variable byte file of new application data, andsending (step 226) the standard variable byte file of new applicationdata via batch process interface/T1 line to the card service engine 104.The unique product control number is also applied to any physicalapplication, which is also sent to retention. In an exemplaryembodiment, this file does not contain any service partner 106 memberdata.

In addition to accomplishing the initial processing of new applicationinformation, the service partner 106 produces (step 230) a balancingreport containing the total records of each file and transmits (step231) the report to the primary party 102. The service partner 106 alsoproduces (step 232) a new account aging report of any applicationsgreater than a predetermined period of time, for example, 30 days. Thesereports are utilized by the information administrator 112 after eachtransmission. Finally, the service partner 106 returns (step 233) anypaper applications and aligns (step 234) with the card service engine'sretention guidelines.

Once the initial processing is complete, the card service engine 104receives (step 240) the standard variable byte file from the servicepartner 106 and performs additional processing. This additionalprocessing includes creating (step 241) necessary codes and updating(step 242) related tables required to identify the new consumer and theservice partner 106 products, creating (step 243) a consolidateddecisioning file, sending (step 244) an approved accounts file to thecard service engine 104, processing (step 245) declined applications,updating (step 246) the balancing report containing total records of thetransmitted file, creating (step 247) a job control language process toexecute the information administrator balancing job, and creating (step248) a back-up of the transmitted file and balancing reports inaccordance with the card service engine's current standards. Theconsolidated decisioning file contains approved, declined, and cancelledservice partner application information.

The customer service administrator 114 extracts (step 250) all approved,declined, and cancelled service partner application information from thecard service engine's consolidated decisioning file and transmits (step251) a billing data file that is sorted, first by product control numberand then by sequence number, to the service partner 106 containing dataon approved, declined, and cancelled service partner accounts, excludingpending applications. The customer service administrator 114 alsoproduces (step 252) a balancing report containing total records of thetransmitted file and creates a job control language process to executethe information administrator balancing job after receiving the servicepartner's transmission report. Finally, the customer serviceadministrator 114 creates (step 253) a back-up of the transmitted fileand balancing report with an expiration of 90 days.

With all declined or cancelled applications, the billing data filecontains the transaction date, the product control number, the cardmember's name, the sequence number, and the status code indicatingwhether the status is approved, declined, or cancelled. With allapproved applications, the billing data file contains the transactiondate, the primary party's account number (basic and supplemental), theproduct control number, the card member's name, the sequence number, andthe status code indicating whether the status is approved, declined, orcancelled.

Once the service partner 106 receives the billing data file that wastransmitted by the customer service administrator 114, the servicepartner 106 identifies (step 260) approved accounts by the presence ofan account number issued by the primary party 102 and populates (step261) the service partner's database with the primary party's new accountnumbers. For any unrecognized product control numbers, the servicepartner 106 produces (step 262) a reject report to be used foroperations reconciliation processes. This reject report includes theprimary party's account number, if applicable, the card member's name,the product control numbers, and the transaction date. The servicepartner 106 also produces (step 263) a balancing report containing totalrecords of the received file and transmits (step 264) the report to theprimary party 102. After receiving an approved account file from thecard service engine 104, the card service engine 104 loads (step 270)the file onto its database, creates (step 271) a daily plastic file,and, periodically, sends (step 272) a plastic embossing file to the cardgenerator 120.

The card generator 120, receives (step 280), periodically, the plasticfile from the card service engine 104. Upon receipt of the plastic file,the card generator 120 identifies (step 281) all service partner chargeand lending accounts on the primary party's renewal plastic file andtransmits (step 282) an identified accounts file of all identifiedaccounts to the service partner 106. The identified accounts fileincludes information such as the primary party's account numbers, cardmember 108 names, the card generator processing identifiers, transactiondates, and the primary party's bag ID's. A new identified accounts fileis created periodically for renewal and periodic processing. Balancingreports are also sent (step 283) to show the total number of accountssent to the service partner 106.

Upon receipt of the identified accounts file from the card generator120, the service partner 106 merges (step 290) the identified accountsfile to the service partner 106 database by the primary party's newaccount numbers. The service partner 106 periodically sorts (step 291)the daily file by approved, declined, and cancelled in numericsequential order to create a daily membership file with service partner106 membership information. Finally, the service partner 106 transmits(step 292) the daily membership file to the card generator 120.

For individual members, service partner 106 membership data includes,for example, the service partner membership number, service partnermember since date, service partner member type, and a photo image. Forbusiness members, the data includes the company name, their resale ID,the resale type, and the resale state. In general, other membership dataincludes, for example, a photo image flag indicator, the primary party'snew account number, the card generator processing indicator, processingdata, and the card generator bag-ID.

After transmitting the daily membership file to the card generator 120,the service partner 106 creates (step 293) an exception reject reportcontaining invalid product control numbers, which are account numbersthat did not result in a match on the service partner database. Theexception reject report is used with the operations reconciliationprocess and includes the primary party's account number, card membername, transaction date, the card generator processing indicator, and theprimary party 102 bag-ID. Finally, the service partner 106 produces(step 294) a balancing report containing the total records of thereceived identified accounts file. This balancing report is utilized bythe information administrator 112 after each transmission for balancingwith the card generator 120.

After receiving the updated embossing information file from the servicepartner 106, the card generator 120 merges (step 284), using the primaryparty's new account number, the data from the updated embossinginformation file with the plastic file that was received previously fromthe card service engine 104. In addition, the card generator 120embosses all required primary party 102 data, prints a card membernumber on the signature panel, prints applicable service partnermembership data such as that which is described above, on the back ofthe primary party card, places the service partner membership number inthe third magnetic stripe position, converts the service partnermembership number to a bar code, prints the bar code on the back of themembership card, and sends the membership card to the card member 108.

In addition, the card generator 120 creates (step 285) a reject reportfor all non-primary party account numbers or invalid card generatorprocessing indicators received from the service partner 106. This rejectreport includes all data received on the service partner file except aphoto image. The report is labeled “Invalid Accounts Received fromService Partner” and is used for operational reconciliation.

Finally, the card generator 120 re-sends, in a subsequent transmissionto the service partner 106, namely account numbers that do not have aservice partner membership number. After a predetermined number ofattempts, the information is removed from the embossing file and placedon the card generator's reject report. Balancing reports show the totalnumber of accounts received from the service partner 106.

Card Replacement Processes. In an exemplary card replacement process,multiple process participants cooperate to accomplish the process steps.The process participants may include only the primary party 102, thecard service engine 104, and the service partner 106, but thoseparticipants may also delegate their responsibilities to entities withintheir respective organizations or to other entities. Furthermore, thecard service engine 104 may be the same party as either the primaryparty 102 or the service partner 106. Regardless to which entities thevarious process steps are delegated, the card replacement process may beinitiated by the primary party 102, in conjunction with the card member108, or by the service partner 106. Further, special procedures may becalled out in cases of fraud or emergency. In an exemplary embodiment,after initial processing, a plastic card replacement process isinitiated.

Referring to FIGS. 3a and 3b, if a card member 108 requests (step 310)card replacement, the card replacement administrator 116 updates (step311) the plastic replacement request with the card service engine 104and thereby initiates the plastic card replacement process. If a cardmember 108 reports (step 320) fraudulent activity on an account, thereport is sent (step 321) to the fraud resolution administrator 118,which attempts (step 322) to solve the case and, if the claim is deemedvalid, sends (step 323) a request to the card replacement administrator116, which updates (step 324) the plastic replacement request with thecard service engine 104 and thereby initiates the plastic cardreplacement process.

If a card member 108 requests (step 330) emergency card replacement, thecard replacement administrator 116 updates (step 331) the card serviceengine 104 to not issue a plastic card and updates the card server,which sends (step 332) embossing information to the card generator 120,which embosses (step 333) the plastic and sends it to the card member108. In an exemplary embodiment, these emergency cards do not containany service partner data and expire at the end of the following monthunless otherwise requested by the card member 108. In addition, the cardreplacement administrator 116 issues (step 334) a second request to thecard service engine 104 to issue service partner replacement plastic,thereby initiating the standard card replacement process. In cases ofemergency card replacement, the card member 108 is notified (step 335),first, that emergency card replacement plastic will preferably notcontain service partner membership data and that the card member 108should seek assistance from the service partner membership desk, second,that multiple-service card re-issuance will occur and will be receivedwithin a predetermined period of time, and third, that additional cardson the account may be required to be replaced if the service partner 106determines that there are changes to membership information.

The service partner 106 may initiate card replacement by updating (step340) the service partner data and sending (step 341) a file to the cardreplacement administrator 116 indicating the card members 108 whorequire new plastic cards. The service partner 106 also produces (step342) a balancing report containing the total records of the transmittedfile and transmits the report to the primary party 102. This report isused by the information administrator 112 after each transmission forbalancing with the card generator 120.

After receiving (step 350) the updated service partner data file fromthe service partner 106, the customer service administrator 114 reads(step 351) the file and sends (step 352) a request to the cardreplacement administrator 116 to create replacement plastic cards. Thecustomer service administrator 114 also creates (step 353) a rejectreport with the card replacement administrator 116 indicating servicepartner replacements that have invalid account numbers. Next, thecustomer service administrator 114 produces (step 354) a balancingreport containing the total records of the transmitted/received file.The customer service administrator 114 also creates (step 355) a jobcontrol language process to execute the information administrator'sbalancing job. Finally, the customer service administrator 114 creates(step 356) a back-up of the service partner replacement request file andbalancing reports for a predetermined period of time, for example, 90days.

Upon receipt (step 360) of the request from the customer serviceadministrator 114 to create replacement plastic cards, the cardreplacement administrator 116 updates (step 361) the plastic replacementrequest with the card service engine 104 and thereby initiates theplastic card replacement process.

As previously stated, the plastic card replacement process is initiatedby a party's updating the plastic replacement request with the cardservice engine 104. Upon receipt of such an update, the card serviceengine 104 creates (step 370) a daily plastic file and sends (step 371)a daily plastic embossing file to the card generator 120.

Upon receipt (step 380) of the daily plastic embossing file from thecard service engine 104, the card generator 120 segments (step 381)service partner accounts and sends (step 382) a file of all identifiedservice partner accounts to the service partner 106. This file istransmitted daily and contains the primary party's account number, thecard member's name, the card generator processing identifier,transaction date, and the primary party's bag ID. Separate files arecreated for renewal and daily processing. Balancing reports are alsosent (step 383) showing total number of accounts sent to the servicepartner 106.

Upon receipt (step 382) of the file showing all identified servicepartner accounts, the service partner 106 merges (step 384) the datacontained in the file to the service partner database according to theprimary party's new account number. At this point, the service partner106 may also need to determine (step 385) whether additional cardmembers 108 in the relationship require their cards to be replaced dueto any changes in service partner membership data. Next, the servicepartner 106 sorts (step 386) the daily file by the basic cards first,then the supplemental cards, in numeric sequential order. In addition,the service partner 106 creates (step 387) an embossing information filewith any new service partner membership data and transmits (step 388)the embossing information file to the card generator 120. The servicepartner 106 also creates (step 389) an exception reject report foraccount numbers that did not result in a match on the service partnerdatabase. This report is for use with the operations reconciliationprocess and includes the primary party's account number, card member'sname transaction date, the card generator processing indicator, and theprimary party bag-ID. Finally, the service partner produces a balancingreport containing total records of the received file.

Upon receipt of the embossing information file from the service partner106, the card generator 120 merges (step 390) the data from the servicepartner's embossing information file with the daily plastic embossingfile previously received from the card service engine 104. For newaccount numbers that do not have a service partner membership number,plastic cards will not be embossed. Next, the card generator 120embosses (step 391) the plastic cards and sends (step 392) thereplacement cards to the card members 108. The card generator 120 alsogenerates (step 393) a reject report for all non-primary party accountnumbers or invalid card generator processing indicators received fromthe service partner 106. This report includes all data received on theservice partner file except the photo image. The report is labeled“invalid accounts received from service partner,” and the report is usedfor operational reconciliation. Finally, the card generator 120 re-sends(step 394) to the service partner account numbers that did not have aservice partner membership number. These account numbers are sent in asubsequent transmission. After a predetermined number of attempts, theinformation is removed (step 395) from the embossing file and placed onthe PDR reject report.

Card Maintenance Processes/Service Partner Membership Cancellation: Inan exemplary service partner membership cancellation process, multipleprocess participants cooperate to accomplish the process steps. Theprocess participants may include only the primary party 102, the cardservice engine 104, and the service partner 106, but those participantsmay also delegate their responsibilities to entities within theirrespective organizations or to other entities. Furthermore, the cardservice engine 104 may be the same party as either the primary party 102or the service partner 106. Referring to FIG. 4, regardless to whichentities the various process steps are delegated, the service partnermembership cancellation process is initiated by the service partner 106,which transmits (step 410) a cancellation file to the primary party 102.The cancellation file contains data elements for all the primary party102 card members 108 who have cancelled their service partnermemberships. These data elements include the cancellation date, theprimary party's new account number, and the card member's name.

Upon receipt of the cancellation file from the service partner 106, theprimary party 102 produces (step 420) a service partner membershipcancellation report on the report generator. This report is used by cardservice providers to transfer (step 430) card members 108 to a newproduct. The primary party 102 also sends (step 421) a report to thecustomer service administrator 114 and produces (step 422) a balancingreport containing total records of the received cancellation file. Inaddition, the primary party 102 creates (step 423) a job controllanguage process to execute the information administrator balancing job.Finally, the primary party 102 creates (step 424) a backup of theservice partner's cancellation file and balancing reports for 90 days.

Card Maintenance Processes/Primary Party Card Member Cancellations orTransfers to non-Service Partner Products: In an exemplary card membercancellation process, multiple process participants cooperate toaccomplish the process steps. The process participants may include onlythe primary party 102, the card service engine 104, and the servicepartner 106, but those participants may also delegate theirresponsibilities to entities within their respective organizations or toother entities. Furthermore, the card service engine 104 may be the sameparty as either the primary party 102 or the service partner 106.Referring to FIGS. 5a and 5b, regardless to which entities the variousprocess steps are delegated, the card member cancellation process isinitiated by the primary party's customer service administrator's 114receiving (step 510) a request from a card member 108 to terminate orconvert to another product.

If the card member 108 requests not to terminate, and the card member108 specifies a product, to which the card member 108 wants to transfer,the customer service administrator 114 opens (step 520) a memo queue andinserts (step 521) a notation indicating that the card member 108 wantsto transfer to a specific product. In addition, the customer serviceadministrator 114 opens (step 522) a memo list and obtains (step 523)accounts that must be transferred to a new IA. Finally, the customerservice administrator 114 processes (step 524) the advancement of therebate and performs the migration transaction to move the card member108 to the new product.

If the card member 108 wants to terminate, or if the card member 108fails to specify a product, to which the card member 108 wants totransfer, the customer service administrator 114 dial transfers (step530) the card member 108 to the membership administrator, which verifies(step 531) that the card member 108 wants to terminate.

If the card member's desire to terminate cannot be verified, themembership administrator identifies (step 540) card member transferoptions and opens (step 541) a memo queue specifying the product, towhich the card member 108 wants to transfer. In addition, the customerservice administrator 114 opens (step 542) a memo list and obtains (step543) accounts that must be transferred to a new IA. Finally, thecustomer service administrator 114 processes (step 544) the advancementof the rebate and performs (step 545) the migration transaction to movethe card member 108 to the new IA.

If the card member's 108 desire to terminate is verified, the membershipadministrator processes (step 550) the attrition, causing the cardservice engine 104 to update (step 551) the file with a cancel code. Inaddition, the card service engine 104 creates (step 552) and/or updates(step 553) the change/renewal file with the transfer code for extractionby the customer service administrator 114.

Once the customer service administrator 114 has extracted (step 560)service partner/primary party accounts from the change/renewal file, thecustomer service administrator 114 creates (step 561) a cancellationfile of all card members 108 who have cancelled their multiple-servicecard. Next, the customer service administrator 114 transmits (step 562)the cancellation file to the service partner 106 and produces (step 563)a primary party/service partner co-brand card cancellation report on thereport generator. This report will be utilized by card provider servicesto transfer (step 570) card members 108 to a new primary party product.The customer service administrator 114 also produces (step 571) abalancing report containing total records of the transmitted file andcreates (step 572) a job control language process to execute theinformation administrator balancing job. Finally, the primary party 102creates (step 573) a backup of the service partner cancellation file andbalancing reports for 90 days.

Upon receipt (step 580) of the primary party's cancellation file fromthe customer service administrator 114, the service partner 106 turnsthe credit flag indicator to N, thereby severing (step 581) the systemlinkage. In this situation, the service partner 106 may issue (step 582)a stand alone membership card. Finally, the service partner 106 produces(step 583) a balancing report containing the total records of thetransmitted file. This balancing report will be utilized (step 584) bythe information administrator 112 after each transmission for balancingwith the card generator 120.

As one skilled in the art will appreciate, the above describedtransaction entry interface, as well as any or all other aspects of thepresent invention, may include any suitable form of encryption and/orother security measures either currently known or hereafter devised.

The present invention provides a system and method for a RF operabletransaction instrument configured to manage multiple data sets (e.g.,“application tenants”) of differing formats associated with a pluralityof distinct transaction account issuers. In this context, an“application tenant” may include all or any portion of any data setswhich are substantially correlated to an account issuer, which theissuer may additionally use to substantially identify an instrument useror related account. For example, where the account issuer providesapplication tenant information, the application tenant may include,inter alia, a membership identifier associated with a user enrolled in aissuer provided transaction account program, and all related subsets ofdata stored on the transaction instrument. Where multiple applicationtenants are referred to herein, each tenant may constitute its owndistinct data set, independent of any other application tenant datasets. For example, each application tenant may include a uniquemembership identifier and all associated subsets of data. Alternatively,an application tenant may include a membership identifier and anapplication for processing all data owned by an issuer. Thus, the dataset or subset may include the processing application. Moreover,differing formats, as discussed herein, include differences in all orany portion of the formats. As such, “application tenant” and “distinctdata set,” and data set “owner” and account “issuer” may be usedinterchangeably herein.

In addition, it should be noted that although the present invention isdescribed with respect to a financial transaction instrument, theinvention is not so limited. The invention is suitable for anyinstrument capable of storing distinct data sets which may be providedby multiple distinct account issuers where the distinct data sets may beformatted one different from another. The account may be, for example, acalling card, a loyalty, debit, credit, incentive, direct debit,savings, financial, membership account or the like. While theinformation provided by the account issuers may be described as being“owned” by the issuers, the issuers or their designees may simply be amanager of the account.

The present invention may be described herein in terms of functionalblock components, optional selections and/or various processing steps.It should be appreciated that such functional blocks may be realized byany number of hardware and/or software components configured to performthe specified functions. For example, the present invention may employvarious integrated circuit components (e.g., memory elements, processingelements, logic elements, look-up tables, and/or the like), which maycarry out a variety of functions under the control of one or moremicroprocessors or other control devices. Similarly, the softwareelements of the present invention may be implemented with anyprogramming or scripting language such as C, C++, Java, COBOL,assembler, PERL, Visual Basic, SQL Stored Procedures, extensible markuplanguage (XML), with the various algorithms being implemented with anycombination of data structures, objects, processes, routines or otherprogramming elements. Further, it should be noted that the presentinvention may employ any number of conventional techniques for datatransmission, signaling, data processing, network control, and/or thelike. For a basic introduction of cryptography and network security, thefollowing may be helpful references: (1) “Applied Cryptography:Protocols, Algorithms, And Source Code In C,” by Bruce Schneier,published by John Wiley & Sons (second edition 1196); (2) “JavaCryptography,” by Jonathan Knudson, published by O'Reilly & Associates(1998); and (3) “Cryptography and Network Security: Principles andPractice,” by Mayiam Stalling, published by Prentice Hall; all of whichare hereby incorporated by reference.

As used herein, the terms “user,” “end user,” “consumer,” “customer” or“participant” may be used interchangeably with each other, and eachshall mean any person, entity, machine, hardware, software and/orbusiness. Furthermore, the terms “business” or “merchant” may be usedinterchangeably with each other and shall mean any person, entity,machine, hardware, software or business. Further still, the merchant maybe any person, entity, software and/or hardware that is a provider,broker and/or any other entity in the distribution chain of goods orservices. For example, the merchant may be a ticket/event agency (e.g.,Ticketmaster, Telecharge, Clear Channel, brokers, agents).

The systems and/or components of the systems discussed herein may alsoinclude one or more host servers or other computing systems including aprocessor configured to process digital data, a memory coupled to theprocessor for storing digital data, an input digitizer coupled to theprocessor for inputting digital data, an application program stored inthe memory and accessible by the processor for directing processing ofdigital data by the processor, a display coupled to the processor andmemory for displaying information derived from digital data processed bythe processor and a plurality of databases, the databases includingclient data, merchant data, financial institution data and/or like datathat could be used in association with the present invention. As thoseskilled in the art may appreciate, the user interface for each systemdescribed herein may typically include an operating system (e.g.,Windows NT, 195/98/2000, Linux, Solaris, etc.) as well as variousconventional support software and drivers typically associated withcomputers. The user computer and other systems described herein can bein a home or business environment with access to a network. In anexemplary embodiment, access is through the Internet through acommercially-available web-browser software package.

Communication between various elements of the present invention isaccomplished through any suitable communication means, such as, forexample, a telephone network, intranet, Internet, point of interactiondevice (point of sale device, personal digital assistant, cellularphone, kiosk, etc.), online communications, off-line communications,wireless communications, and/or the like. One skilled in the art mayalso appreciate that, for security reasons, any databases, systems, orcomponents of the present invention may consist of any combination ofdatabases or components at a single location or at multiple locations,wherein each database or system includes any of various suitablesecurity features, such as firewalls, access codes, encryption,decryption, compression, decompression, and/or the like.

The systems may be suitably coupled to the network via data links. Avariety of conventional communications media and protocols may be usedfor data links. For example, a connection to an Internet ServiceProvider (ISP) over the local loop as is typically used in connectionwith standard modem communication, cable modem, Dish networks, ISDN,Digital Subscriber Line (DSL), or various wireless communicationmethods. The merchant system might also reside within a local areanetwork (LAN) that interfaces to the network via a leased line (T1, D3,etc.). Such communication methods are well known in the art and arecovered in a variety of standard texts. See, e.g., Gilbert Held,“Understanding Data Communications,” (1996), hereby incorporated byreference.

The computing units may be connected with each other via a datacommunication network. The network may be a public network and assumedto be insecure and open to eavesdroppers. In the illustratedimplementation, the network may be embodied as the Internet. In thiscontext, the computers may or may not be connected to the Internet atall times. For instance, the customer computer may employ a modem tooccasionally connect to the Internet, whereas the bank computing centermight maintain a permanent connection to the Internet. Specificinformation related to the protocols, standards, and applicationsoftware utilized in connection with the Internet may not be discussedherein. For further information regarding such details, see, forexample, Dilip Naik, “Internet Standards and Protocols,” (1998); “Java12 Complete,” various authors (Sybex 1999); Deborah Ray and Eric Ray,“Mastering HTML 14.0”(1997); Loshin, “TCP/IP Clearly Explained,” (1997).All of these texts are hereby incorporated by reference.

It may be appreciated that many applications of the present inventioncould be formulated. One skilled in the art may appreciate that anetwork may include any system for exchanging data or transactingbusiness, such as the Internet, an intranet, an extranet, WAN, LAN,satellite communications, and/or the like. It is noted that the networkmay be implemented as other types of networks, such as an interactivetelevision (ITV) network. The users may interact with the system via anyinput device such as a keyboard, mouse, kiosk, personal digitalassistant, handheld computer (e.g., Palm Pilot®), cellular phone and/orthe like. Similarly, the invention could be used in conjunction with anytype of personal computer, network computer, workstation, mini-computer,mainframe, or the like running any operating system such as any versionof Windows, Windows NT, Windows2000, Windows 198, Windows 195, MacOS,OS/2, BeOS, Linux, UNIX, Solaris or the like. Moreover, although theinvention is frequently described herein as being implemented withTCP/IP communications protocols, it may be readily understood that theinvention could also be implemented using IPX, Appletalk, IP-6, NetBIOS,OSI or any number of existing or future protocols. Moreover, the presentinvention contemplates the use, sale or distribution of any goods,services or information over any network having similar functionalitydescribed herein.

In accordance with various embodiments of the invention, the InternetInformation Server, Microsoft Transaction Server, and Microsoft SQLServer, are used in conjunction with the Microsoft operating system,Microsoft NT web server software, a Microsoft SQL database system, and aMicrosoft Commerce Server. Additionally, components such as Access orSQL Server, Oracle, Sybase, Informix MySQL, Interbase, etc., may be usedto provide an ADO-compliant database management system. The term“webpage” as it is used herein is not meant to limit the type ofdocuments and applications that might be used to interact with the user.For example, a typical website might include, in addition to standardHTML documents, various forms, Java applets, Javascript, active serverpages (ASP), common gateway interface scripts (CGI), extensible markuplanguage (XML), dynamic HTML, cascading style sheets (CSS), helperapplications, plug-ins, and/or the like.

The financial transaction instrument (e.g., smart card, magnetic stripecard, bar code card, optical card, biometric device, radio frequencycard or transponder and/or the like) may communicate to the merchant,information from one or more data sets associated with the financialtransaction instrument. In one example, membership data and credit carddata associated with an account or card may be transmitted using anyconventional protocol for transmission and/or retrieval of informationfrom an account or associated transaction card (e.g., credit, debit,loyalty, etc.). In one exemplary embodiment, the transaction instrumentmay be configured to communicate via RF signals. As such, the datacontained on the instrument may be communicated via radio frequencysignals.

A financial transaction instrument may include one or more physicaldevices used in carrying out various financial transactions. Forexample, a financial transaction instrument may include a rewards card,charge card, credit card, debit card, prepaid card, telephone card,smart card, magnetic stripe card, radio frequency card/transponderand/or the like. In yet another exemplary embodiment of the presentinvention, a financial transaction instrument may be an electroniccoupon, voucher, and/or other such instrument.

The financial transaction instrument in accordance with this inventionmay be used to pay for acquisitions, obtain access, provideidentification, pay an amount, receive payment, redeem reward pointsand/or the like. In the radio frequency (“RF”) embodiments of thetransaction instrument, instrument to instrument transactions may alsobe performed. See, for example, Sony's “Near Field Communication”(“NFC”) emerging standard which is touted as operating on 113.56 MHz andallowing the transfer of any kind of data between NFC enabled devicesand across a distance of up to twenty centimeters. See also, Bluetoothchaotic network configurations; described in more detail athttp://www.palowireless.com/infotooth/whatis.asp, which is incorporatedherein by reference. Furthermore, data on a first RF device may betransmitted directly or indirectly to another RF device to create a copyof all or part of the original device.

Furthermore, financial transaction instrument as described herein may beassociated with various applications which allow the financialtransaction instruments to participate in various programs, such as, forexample, loyalty programs. A loyalty program may include one or moreloyalty accounts. Exemplary loyalty programs include frequent flyermiles, on-line points earned from viewing or purchasing products orwebsites on-line and programs associated with diner's cards, creditcards, debit cards, hotel cards, calling cards, and/or the like.Generally, the user is both the owner of the transaction card accountand the participant in the loyalty program; however, this association isnot necessary. For example, a participant in a loyalty program may giftloyalty points to a user who pays for a purchase with his owntransaction account, but uses the gifted loyalty points instead ofpaying the monetary value.

For more information on loyalty systems, transaction systems, andelectronic commerce systems, see, for example, U.S. Utility patentapplication Ser. No. 10/304,251, filed on Nov. 16, 1002, by inventorsAntonucci, et al., and entitled “System and Method for Transfer ofLoyalty Points”; U.S. Continuation-In-Part patent application Ser. No.10/378,456, filed on Mar. 13, 1003, by inventors Antonucci, et al., andentitled “System and Method for the Real-Time Transfer of Loyalty PointsBetween Accounts”; U.S. patent application Ser. No. 09/836,213, filed onApr. 17, 1001, by inventors Voltmer, et al., and entitled “System AndMethod For Networked Loyalty Program”; U.S. Continuation-In-Part patentapplication Ser. No. 10/027,984, filed on Dec. 10, 1001, by inventorsAriff, et al., and entitled “System And Method For Networked LoyaltyProgram”; U.S. Continuation-In-Part patent application Ser. No.10/010,947, filed on Nov. 16, 1001, by inventors Haines, et al., andentitled “System And Method For Networked Loyalty Program”; U.S.Continuation-In-Part patent application Ser. No. 10/084,744, filed onFeb. 16, 1002, by inventors Bishop, et al, and entitled “System AndMethod For Securing Data Through A PDA Portal”; the Shop AMEX™ system asdisclosed in Ser. No. 10/230,190, filed Sep. 15, 2000; the Loyalty AsCurrency™ and Loyalty Rewards Systems disclosed in Ser. No. 10/197,296,filed on Apr. 14, 2000, Ser. No. 10/200,492, filed Apr. 18, 2000, Ser.No. 10/201,114, filed May 12, 2000; a digital wallet system disclosed inU.S. Ser. No. 09/652,899, filed Aug. 11, 2000; a stored value card asdisclosed in Ser. No. 09/241,188, filed on Feb. 11, 1999; a system forfacilitating transactions using secondary transaction numbers disclosedin Ser. No. 09/800,461, filed on Mar. 17, 2001, and also in relatedprovisional applications Ser. No. 10/187,620, filed Mar. 17, 2000, Ser.No. 10/200,625, filed Apr. 18, 2000, and Ser. No. 10/213,323, filed May12, 2000, all of which are herein incorporated by reference. Otherexamples of online loyalty systems are disclosed in “Netcentives,” U.S.Pat. No. 5,774,870, issued on Jun. 10, 1998, and U.S. Pat. No.5,009,412, issued on Dec. 19, 1999, both of which are herebyincorporated by reference.

Further still, a “code,” “account,” “account number,” “identifier,”“loyalty number” or “membership identifier,” as used herein, includesany device, code, or other identifier/indicia suitably configured toallow the consumer to interact or communicate with the system, such as,for example, authorization/access code, personal identification number(PIN), Internet code, other identification code, and/or the like that isoptionally located on a rewards card, charge card, credit card, debitcard, prepaid card, telephone card, smart card, magnetic stripe card,bar code card, radio frequency card and/or the like. The account numbermay be distributed and stored in any form of plastic, electronic,magnetic, radio frequency, audio and/or optical device capable oftransmitting or downloading data from itself to a second device. Acustomer account number may be, for example, a sixteen-digit credit cardnumber, although each credit provider has its own numbering system, suchas the fifteen-digit numbering system used by an exemplary loyaltysystem. Each company's credit card numbers comply with that company'sstandardized format such that the company using a sixteen-digit formatmay generally use four spaced sets of numbers, as represented by thenumber “0000 0000 0000 0000.” The first five to seven digits arereserved for processing purposes and identify the issuing bank, cardtype and etc. In this example, the last sixteenth digit is used as a sumcheck for the sixteen-digit number. The intermediary eight-to-ten digitsare used to uniquely identify the customer. In addition, loyalty accountnumbers of various types may be used.

Further yet, the “transaction information” in accordance with thisinvention may include the nature or amount of transaction, as well as, amerchant, user, and/or issuer identifier, security codes, or routingnumbers, and the like. In various exemplary embodiments of the presentinvention, one or more transaction accounts may be used to satisfy orcomplete a transaction. For example, the transaction may be onlypartially completed using the transaction account(s) correlating to theapplication tenant information stored on the transaction instrument withthe balance of the transaction being completed using other sources. Cashmay be used to complete part of a transaction and the transactionaccount associated with a user and the transaction instrument, may beused to satisfy the balance of the transaction. Alternatively, the usermay identify which transaction account, or combination of transactionaccounts, stored on the transaction instrument the user desires tocomplete the transaction. Any known or new methods and/or systemsconfigured to manipulate the transaction account in accordance with theinvention may be used.

In various exemplary embodiments, the financial transaction instrumentmay be embodied in form factors other than, for example, a card-likestructure. As already mentioned, the financial transaction instrumentmay comprise an RF transponder, a speed pass, store discount card, orother similar device. Furthermore, the financial transaction instrumentmay be physically configured to have any decorative or fanciful shapeincluding key chains, jewelry and/or the like. The financial transactioninstrument may furthermore be associated with coupons. A typical RFdevice which may be used by the present invention is disclosed in U.S.application Ser. No. 10/192,488, entitled “System And Method For PaymentUsing Radio Frequency Identification In Contact And ContactlessTransactions,” and its progeny, which are all commonly assigned, andwhich are all incorporated herein by reference.

As used herein, the term “data set” may include any set of informationand/or the like which may be used, for example, in completing atransaction. For example, data sets may include information related tocredit cards, debit cards, membership clubs, loyalty programs, speedpass accounts, rental car memberships, frequent flyer programs, coupons,tickets and/or the like. This information may include membershipidentifiers, account number(s), personal information, balances, pasttransaction details, account issuer routing number, cookies,identifiers, security codes, and/or any other information. The data setmay additionally include an issuer defined management process fordetermining which subsets of data are to be provided to an issuer ormerchant. In some instances, a data set may be associated with one ormore account numbers corresponding to accounts maintained by the accountissuer.

The various data sets associated with a financial transaction instrumentmay either be stored on the financial transaction instrument itself orremotely. In one exemplary embodiment, the financial transactioninstrument itself is configured to store at least two data sets. Inother exemplary embodiments, data sets may be stored in one or moredatabases and the data sets are affiliated with the financialtransaction instrument. For example, a central database on theinstrument may store multiple distinct data sets correlated with aunique issuer. The data sets stored on the remote database may be storedthereon, in such a manner as to mimic the corresponding data sets storedon the transaction instrument. The multiple distinct data sets may beaccessed, for example, by a merchant system, whether stored on thetransaction instrument or remote database stand alone device, and/or acomputer user interface, via a network. In this example, the financialtransaction instrument may include one or more user identifiers (e.g.,membership identifiers), which may be used to provide access to a subsetof data included on the financial transaction instrument.

Various information and data are described herein as being “stored.” Inthis context, “stored” may mean that the information is kept on adatabase. In accordance with the invention, a database may be any typeof database, such as relational, hierarchical, object-oriented, and/orthe like. Common database products that may be used to implement thedatabases include DB2 by IBM (White Plains, N.Y.), any of the databaseproducts available from Oracle Corporation (Redwood Shores, Calif.),Microsoft Access or MSSQL by Microsoft Corporation (Redmond, Wash.), orany other database product. A database may be organized in any suitablemanner, including as data tables or lookup tables. Association ofcertain data may be accomplished through any data association techniqueknown and/or practiced in the art. For example, the association may beaccomplished either manually or automatically. Automatic associationtechniques may include, for example, a database search, a databasemerge, GREP, AGREP, SQL, and/or the like. The association step may beaccomplished by a database merge function, for example, using a “keyfield” in each of the manufacturer and retailer data tables. A “keyfield” partitions the database according to the high-level class ofobjects defined by the key field. For example, a certain class may bedesignated as a key field in both the first data table and the seconddata table, and the two data tables may then be merged on the basis ofthe class data in the key field. In this embodiment, the datacorresponding to the key field in each of the merged data tables ispreferably the same. However, data tables having similar, though notidentical, data in the key fields may also be merged by using AGREP, forexample.

Although all data sets associated with a particular financialtransaction instrument may be owned by the same owner, it iscontemplated that in general, some of the data sets stored on thefinancial transaction instrument have different owners. Furthermore, thestorage of data sets is configured to facilitate independent storage andmanagement of the data sets on the financial transaction instrument.Further still, the data sets may be stored in distinct differing formatsprovided by the distinct issuer or data set owner (also called “issuer,”herein). The owners of data sets may include different individuals,entities, businesses, corporations, software, hardware, and/or the like.However, one skilled in the art will appreciate that the owners may alsoinclude different divisions or affiliates of the same corporation orentity.

A data set may contain any type of information stored in digital format.For example, a data set may include account numbers,programs/applications, scripts, cookies, instruments for accessing otherdata sets, and/or any other information.

As discussed above, many issuers of existing financial transactioninstruments utilize predetermined formats for account numbers, dataand/or applications stored in association with the financial transactioninstrument. Similarly, the data storage media associated with thesefinancial transaction instruments are typically configured toaccommodate specific predetermined data formats. Thus, since the dataformat associated with a first issuer is often different from a dataformat of a second issuer, storage of multiple distinct data ofdiffering formats on a single device provides complications forconventional systems. This is true since, each issuer typicallymaintains an account processing system that uses a processing protocoldifferent from other issuers, and the information stored on thetransaction card relative to the issuer must be formatted accordingly.As such, to ensure the security and integrity of the issuer-owned data,the loading of data on a transaction instrument is typically performedby an issuer or a third-party provider who typically uploads all relatedand similarly formatted data sets onto the transaction instrument.However, since the third party may typically only be authorized by theissuer to load issuer-owned data of similar format onto anissuer-provided transaction device, including differently formatted datasets on a single transaction device by the third party is often notpermitted. More particularly, independent owners of data sets are oftenreluctant to conform their data set formats to a “standard format”because of the security advantages of maintaining a separate, distinct,often secreted format.

In contrast, and in accordance with an exemplary embodiment of thepresent invention, the format of the information stored in the presentinvention may vary from one data set to another. That is, the presentinvention permits the data to be stored on the financial transactioninstrument in any format, and more particularly, in any formatrecognizable by the data owner/transaction instrument issuer. Thus, asnoted, each data set may be used for a very wide variety of purposesincluding storage of applications, raw data, cookies, coupons,membership data, account balances, loyalty information, and/or the like.

In accordance with one aspect of the present invention, any suitabledata storage technique may be utilized to store data without a standardformat. Data sets may be stored using any suitable technique, including,for example, storing individual files using an ISO/IEC 17816-4 filestructure; implementing a domain whereby a dedicated file is selectedthat exposes one or more elementary files containing one or more datasets; using data sets stored in individual files using a hierarchicalfiling system; data sets stored as records in a single file (includingcompression, SQL accessible, hashed via one or more keys, numeric,alphabetical by first tuple, etc.); block of binary (BLOB); stored asungrouped data elements encoded using ISO/IEC 17816-6 data elements;stored as ungrouped data elements encoded using ISO/IEC Abstract SyntaxNotation (ASN.1) as in ISO/IEC 18824 and 18825; and/or other proprietarytechniques that may include fractal compression methods, imagecompression methods, etc.

In one exemplary embodiment, the ability to store a wide variety ofinformation in different formats is facilitated by storing theinformation as a Block of Binary (BLOB). Thus, any binary informationcan be stored in a storage space associated with a data set. Asdiscussed above, the binary information may be stored on the financialtransaction instrument or external to but affiliated with the financialtransaction instrument. The BLOB method may store data sets as ungroupeddata elements formatted as a block of binary via a fixed memory offsetusing either fixed storage allocation, circular queue techniques, orbest practices with respect to memory management (e.g., paged memory,memory recently used, etc.). By using BLOB methods, the ability to storevarious data sets that have different formats facilitates the storage ofdata associated with the financial transaction instrument by multipleand unrelated owners of the data sets. For example, a first data setwhich may be stored may be provided by a first issuer, a second data setwhich may be stored may be provided by an unrelated second issuer, andyet a third data set which may be stored, may be provided by a thirdissuer unrelated to the first and second issuers. Each of these threeexemplary data sets may contain different information that is storedusing different data storage formats and/or techniques. Further, eachdata set may contain subsets of data which also may be distinct fromother subsets.

Even further, where the invention contemplates the use of a self-serviceuser interaction device. In this context, the self-service userinteraction device may be any device suitable for interacting with atransaction instrument, and receiving information from the transactioninstrument user and providing the information to a merchant, accountissuer, account manager, data set owner, merchant point of sale, and thelike. For example, the self-service user interaction device may be astand alone read write device, self-service Kiosk, merchant point ofsale, read/write device, and the like. In one example, the self-serviceuser interaction device may be configured to communicate information toand from the transaction device and to manipulate the data sets storedthereon. The self-service interaction device may be in communicationwith the various components of the invention using any communicationsprotocol.

In general, systems and methods disclosed herein, are configured tofacilitate the management of multiple distinct data sets associated witha financial transaction instrument. Management of data sets may includesuch steps as adding, augmenting, updating and/or deleting data setsassociated with the financial transaction instrument. Such manipulationsof the data may occur without replacing or reissuing the financialtransaction instrument. With reference to FIG. 6, an exemplary method1100 according to the present invention is shown. Method 1100 mayinclude issuing a financial transaction instrument issued to atransaction device user (step 1110), enrolling multiple data set ownersin a multiple account on a transaction device program (step 1112), andmanaging data sets associated with the financial transaction instrument(step 1120). In managing the data, the method 1100 may determine, forexample, whether the data should be added to a data set (step 1130),modified (step 1140) or deleted (step 1150), as described more fullybelow. Once the data is appropriately managed, the financial transactioninstrument user may present the data contained on the instrument to amerchant system for completion of a transaction.

The system may be further configured such that, during an exemplarytransaction, data sets associated with the financial transactioninstrument may be managed. For example, the user may be prompted (e.g.,on a screen, by electronic voice, by a store clerk, by a signal and/orthe like) as to the possibility of adding, for example, a loyaltyaccount to the same financial transaction instrument and the user mayalso be presented with terms and/or conditions in a similar or differentmanner. The user may be prompted at any time during the transaction, butpreferably the user is prompted at the completion of the transaction. Ifthe user accepts the invitation to add data to the financial transactioninstrument, a new data set may be added (step 1130) and/or an existingdata set is updated (step 1140). For example, if data is to be updated,the stand alone may locate appropriate data to be updated on thetransaction device, and make the updates (“modifications”) in accordancewith data owner instructions. If the data is to be added, the standalone device may be configured to provide any account information (e.g.,account identifier, security code, data owner routing number, etc.) tothe transaction device for storage thereon. The stand alone may locatean appropriate database location on transaction instrument for storingthe added data. The stand alone device facilitates storage of the datain a distinct location on the transaction device database, where thedata is stored independently of any other data. In a preferredembodiment of the invention, the data is added to a database location onthe transaction device which reserved for independently storing all dataowned by a particular data set owner. Alternatively, the data may bestored in a distinct location on the transaction device, which is aseparate location than is used to store any other data set. Furtherstill, the data set is stored in accordance with any storage protocolpermitting the data to be stored and retrieved independently of otherdata.

The adding and updating of the data may be verified by the issuer, priorto making the modifications. If verified, all databases containing thedata set to be updated or a mirror image of the data set to be updated,are modified in accordance with the user or issuer providedinstructions, and/or the issuer defined data storage protocol or format.

In one exemplary embodiment, multiple account issuers may be enrolled ina multiple account management program using a financial transactioninstrument in accordance with the invention (step 1112). For example,permission for adding account issuer owned data may be obtained from thedata set owner. The data set owner may then be requested to provideaccount information to be stored on a transaction instrument. The dataset owner may then provide account information relative to a distinctuser account for loading onto the transaction instrument in accordancewith the present invention. The issuers may be enrolled prior toissuance of the instrument or the issuers may be enrolled afterissuance. By enrolling in the management program, the issuer may provideauthorization for including the issuer-owned data on the financialtransaction instrument. The issuer-owned data may be included (e.g.,added, deleted, modified, augmented, etc.) on the transaction instrumentusing a stand alone interaction device, merchant system, or userpersonal computer interface upon presentment of the transaction deviceto the stand alone interaction device 1290 (step 1114). The stand aloneinteraction device may manipulate the issuer-owned data while preservinga format recognizable by an issuer account management system. Forexample, the stand alone device may identify the appropriate header ortrailer associated with the data and add, delete or modify the dataaccordingly. The stand alone may manipulate the data using anymanipulation instruction or protocol as provided by the data set ownerso that the resulting manipulated data is in a format recognizable bythe data set owner system. In this way, the stand alone device maymanipulate the data while maintaining the data set owner's format.Alternatively, the interaction device may store the issuer-owned data onthe transaction instrument in any format, provided that the issuer-owneddata is provided to the issuer system (or to merchant system) in anissuer system (or merchant system) recognizable format.

It should be noted, that the financial transaction instrument may beissued with or without one or more data sets stored thereon. Thefinancial transaction instrument may be issued using various techniquesand practices now known or hereinafter developed wherein an instrumentis prepared (e.g., embossed and/or loaded with data) and made availableto a user for effecting transactions. Although the present invention maycontemplate managing data sets (step 1120) before issuing a financialtransaction instrument (step 1110), in various exemplary embodiments, byway of illustration, the data sets are described herein as being managed(step 1120) after issuance (step 1110).

At any time after issuance (step 1110) of the financial transactioninstrument, the financial transaction instrument may be used in acommercial transaction. In one exemplary embodiment of the presentinvention, a user communicates with a merchant, indicates a desire toparticipate in a issuer provided consumer program. The user maycommunicate with the merchant by, for example, presenting thetransaction instrument to the merchant and indicting a desire tocomplete a transaction. The user may indicate his desire to complete atransaction using any conventional process used by the merchant. Theuser may further indicate that the user wished to complete thetransaction using the financial transaction instrument.

During completion of the transaction, the user may present the financialtransaction instrument to a merchant system. The financial transactioninstrument is configured to communicate with the merchant, using anyconventional method for facilitating a transaction over a network.

As stated above, in various embodiments of the present invention, thedata can be stored without regard to a common format. However, in oneexemplary embodiment of the present invention, the data set (e.g., BLOB)may be annotated in a standard manner when provided for manipulating thedata onto the financial transaction instrument. The annotation maycomprise a short header, trailer, or other appropriate indicator relatedto each data set that is configured to convey information useful inmanaging the various data sets. For example, the annotation may becalled a “condition header,” “header,” “trailer,” or “status,” herein,and may comprise an indication of the status of the data set or mayinclude an identifier correlated to a specific issuer or owner of thedata. In one example, the first three bytes of each data set BLOB may beconfigured or configurable to indicate the status of that particulardata set (e.g., LOADED, INITIALIZED, READY, BLOCKED, REMOVABLE, orDELETED). Subsequent bytes of data may be used to indicate for example,the identity of the issuer, user, transaction/membership accountidentifier or the like. Each of these condition annotations are furtherdiscussed herein.

The data set annotation may also be used for other types of statusinformation as well as various other purposes. For example, the data setannotation may include security information establishing access levels.The access levels may, for example, be configured to permit only certainindividuals, levels of employees, companies, or other entities to accessdata sets, or to permit access to specific data sets based on thetransaction, merchant, issuer, user or the like. Furthermore, thesecurity information may restrict/permit only certain actions such asaccessing, modifying, and/or deleting data sets. In one example, thedata set annotation indicates that only the data set owner or the userare permitted to delete a data set, various identified merchants arepermitted to access the data set for reading, and others are altogetherexcluded from accessing the data set. However, other access restrictionparameters may also be used allowing various entities to access a dataset with various permission levels as appropriate.

The data, including the header or trailer may be received from a dataset owner via any communication method described herein. The header ortrailer may be appended to a data set to be modified, added or deleted,to indicate the action to be taken relative to the data set. The dataset owner may provide the to a stand alone interaction device configuredto add, delete, modify, or augment the data in accordance with theheader or trailer. As such, in one exemplary embodiment, the header ortrailer is not stored on the transaction device along with theassociated issuer-owned data but instead the appropriate action may betaken by providing to the transaction instrument user at the stand alonedevice, the appropriate option for the action to be taken. However, thepresent invention contemplates a data storage arrangement wherein theheader or trailer, or header or trailer history, of the data is storedon the transaction instrument in relation to the appropriate data.

In various exemplary embodiments, the steps of adding, deleting,augmenting and/or modifying data sets may be repeated. For example,first, second, and additional data sets may be added (step 1130) to thefinancial transaction instrument in any order. In one exemplaryembodiment of the present invention, the first data set is owned by afirst data set owner (i.e., first issuer) and the second data set isowned by a second data set owner (i.e., second issuer). Furthermore, thesystem may include replacing a first data set with a subsequent data setby deleting a data set (step 1150), then adding a data set (step 1130).

With reference now to FIG. 7, in one exemplary embodiment of the presentinvention, a data set management system (“management system”) 1200comprises a merchant system 1220, various issuer systems 1230, and afinancial transaction instrument 1240. Management system 1200 mayfurther be accessed by a user 1201 on a self-service interaction device,such as, for example, user computer 1250 or via a transaction devicesuch as, for example, kiosk 1270, stand alone interaction device 1290,automated teller, or the like. In these examples, communications betweenuser computer 1250 or kiosk 1270 and merchant system 1220 or issuersystems 1230 may take place via, for example, a network 1260. In variousembodiments, merchant system 1220, user computer 1250 and/or kiosk 1270are configured to communicate with financial transaction instrument1240. For example, communication with the financial transactioninstrument 1240 may be facilitated by a point of read/write device 1280,such as a merchant point of sale, merchant RFID reader, computerinterface, or the like, configured to receive information provided bythe financial transaction instrument 1240.

In general, merchant system 1220 is configured to interact with a user1201 attempting to complete a transaction, and to communicatetransaction data to one or more of issuer systems 1230. Issuer systems1230 are configured to interact with financial transaction instrument1240 to receive and/or exchange data facilitating a transaction.Merchant system 1220 may be operated, controlled and/or facilitated byany merchant that accepts payment via a transaction instrument.

Merchant system 1220 is configured to facilitate interaction with user1201, which may be any person, entity, software and/or hardware. Theuser 1201 may communicate with the merchant in person (e.g., at the boxoffice), or electronically (e.g., from a user computer 1250 via network1260). During the interaction, the merchant may offer goods and/orservices to the user 1201. The merchant may also offer the user 1201 theoption of completing the transaction using a financial transactioninstrument. The merchant system may provide the options to the user 1201using interactive user interface, suitable website or otherInternet-based graphical user interface that is accessible by users.

Each user 1201 may be equipped with a computing system to facilitateonline commerce transactions. For example, the user 1201 may have acomputing unit in the form of a personal computer (e.g., user computer1250), although other types of computing units may be used includinglaptops, notebooks, hand held computers, set-top boxes, and/or the like.The merchant system 1220 may have a computing unit 1222 implemented inthe form of a computer-server, although other implementations arepossible. The issuer system 1230 may have a computing center such as amain frame computer. However, the issuer computing center may beimplemented in other forms, such as a mini-computer, a PC server, anetwork set of computers, or the like.

Issuer system 1230 may be configured to manipulate a transaction accountassociated with the corresponding issuer-owned data stored on thetransaction instrument 1240 (or database 1282, discussed below) inaccordance with a related transaction. For example, the issuer system1230 may receive “transaction information” and manipulate an accountstatus or balance in accordance with the information received. Inaccordance with the transaction amount, the issuer system 1230 may, forexample, diminish a value available for completing a transactionassociated with the account, or the issuer system 1230 may alter theinformation relative to the account user (e.g., demographics, personalinformation, etc.).

It should be noted that issuer systems 1230 may also be configured tointeract with financial transaction instrument 1240, directly orindirectly via database 1282 or stand alone interaction device 1290, toindividually manage data sets on financial transaction instrument 1240.For example, issuer systems 1230 may manage data sets on database 1282.In some embodiments, the data sets on database 1282 may then be storedon financial transaction instrument 1240 when the transaction instrumentis presented. In other embodiments, issuer systems 1230 may store dataset information within their own systems which may communicate with thefinancial transaction instrument via user computer 1250, kiosk 1270, ormerchant system 1220. In such embodiments, the issuer system 1230 may beconfigured to push the data set to the financial transaction instrument1240 via the stand alone interaction device 1290, or the merchant system1220, kiosk 1270, interaction device 1290 or computer 1250 which may beconfigured to pull such information from the issuer system 1230.

In addition, the data may be manipulated using, for example, a standalone interaction device 1290 configured to communicate with at leastone of the issuer systems 1230 which may or may not be configured tocommunicate with a merchant system 1220. The interaction device 1290 maycommunicate with the issuer systems 1230 using any of the aforementionedcommunication protocols, techniques and data links. The communicationbetween the stand alone interaction device 1290 and the issuer system1230 may be facilitated by a network 1260. In an exemplary embodiment,the network 1260 may be secure against unauthorized eavesdropping.

Interaction device 1290 may provide instructions to the issuer systems1230 for requesting receipt of issuer-owned data, such as for example,account data, user member identification data, member demographic data,or the like, which the issuer wishes to store on the financialtransaction instrument 1240. The interaction device 1290 may communicatewith the issuer systems 1230 using an issuer recognizable communicationsprotocol, language, methods of communication and the like, for providingand receiving data. In one exemplary embodiment, issuer-owned data isreceived by the interaction device 1290 from issuer systems 1230, andstored onto the financial transaction instrument 1240. The data may bestored or manipulated in accordance with the issuer providedinstructions, protocol, storage format, header or trailers received bythe interaction device from issuer systems 1230. The issuer-owned datamay be stored on the financial transaction device 1240 in any formatrecognizable by a merchant system 1280, and further recognizable byissuer system 1230. In one exemplary embodiment, the issuer owned datais stored using a issuer system 1230 format which may be later formattedin merchant system 1280 recognizable protocol when provided to themerchant system 1280. In one embodiment, the issuer-owned information isstored on the financial transaction instrument 1240 in the identicalformat with which it was provided by the issuer system 1230. In thatregard, interaction device 1290 may be any device configured to receiveissuer-owned data from an issuer system 1230, and write the data to adatabase, such as, for example, a database on instrument 1240 ordatabase 1282. Further, as described more fully below, the issuer-ownedinformation may also be provided by the issuer 1230 to a remote database1282 where the information is stored such that it mirrors thecorresponding information stored on the transaction instrument 1240.

Interaction device 1290 may be initialized prior to use. For example,the interaction device 1290 may be any system which may be initialized(“configured”) to communicate with a merchant system 1280. Where theinteraction device is not initialized prior to attempting communicationswith the merchant system 1280 or transaction instrument 1240, theinteraction device 1280 may be initialized at the merchant system 1280location. The interaction device may be initialized using anyconventional method for configuring device communication protocol.

As noted, in accordance with the invention a transaction instrument isprovided which permits the storage and presentment of at least one of aplurality of data sets for completing a transaction. The data sets maybe stored on the transaction device itself, or on a remote database, asdescribed below. The data sets stored with regard to the transactioninstrument may be modified, deleted, added or augmented, as required bythe issuer or the user. For example, as owner of the data, an issuer maymodify a data set at the issuer's discretion. The issuer may modify thedata, data subsets, member identifier and/or applications or data setsassociated with its transaction account program. Such modifications maybe completed or substantially completed in substantially real-time or ata later date, for example, when the transaction instrument is nextpresented.

In a typical example of issuer modification of the data sets, one ormore data sets may be modified by the issuer system 1230 directly viathe issuer systems 1230, upon presentment of the financial transactioninstrument 1240 to the system 1230. That is, the user 1201 may presentthe card to the issuer system 1230, and the issuer system 1230 maymodify the issuer data stored thereon, using any issuer definedprotocol. Alternatively, the modifications, or instructions formodification, may be initiated at the issuer system 1230, and providedto the network 1260. The modifications and/or modification instructionsmay additionally be provided to a suitable device configured tocommunicate with the transaction instrument 1240, receive informationregarding the data stored on instrument 1240, and to write or overwritethe information contained on instrument 1240. For example, as noted,interaction device 1290 is a suitable interaction device which may beused to provide information to the transaction instrument 1240 to modifythe information stored thereon. Interaction device 1290 may be anydevice capable of receiving data management instructions from the issuersystems 1230 and for updating the data stored on the transactioninstrument 1240, in accordance with the instructions received. In thisregard, the interaction device 1290 may include any electroniccomponents, databases, processors, servers and the like which may beused to modify the data stored on instrument 1240 using any suitabledata modification protocol as is found in the art. Preferably, theinteraction device is configured to modify the data on the transactiondevice in accordance with a data owner defined protocol.

In one exemplary embodiment, the interaction device 1290, may beconfigured to modify the transaction instrument's 1240 issuer-owned datawhen the instrument 1240 is initially configured, prior to providing theinstrument 1240 to the user 1201. The interaction device 1290 mayadditionally be configured to modify the issuer data on the instrument1240 when the instrument 1240 is next presented, for example, to thestand alone interaction device 1290. In this regard, the interactiondevice 1290 may receive from multiple distinct issuer systems 1230, viathe network 1260, the issuer provided modifications/instructions and mayupdate the instrument 1240 in real-time or substantially real-time. Themodifications may be provided to the interaction device 1290 for storageand later use when the instrument 1240 is next presented. Alternatively,the interaction device 1290 may be configured to retrieve theinstructions from the issuer system 1230 when the instrument 1240 isnext presented to device 1290. Further, where other devices, such as,for example, a kiosk 1270, merchant point of interaction device, or thelike, are likewise configured to modify the issuer data on instrument1240, the invention contemplates that the real-time or substantiallyreal-time modifications noted above may be made using those devices insimilar manner as is described with the interaction device 1290.

Alternatively, the device to which the transaction instrument 1240 maybe presented, may not be equipped for updating or modifying the datastored on the instrument 1240. For example, merchant system 1220 may beany conventional merchant system which communicates to an issuer system1230, and which permits a user 1201 to complete a financial transaction,but which is not configured to modify the issuer data contained on thetransaction instrument. In general, conventional merchant systems arenot configured to write or overwrite data included on the paymentdevices presented to the merchant system for processing. That is, themerchant system 1220 may include little or no additional software toparticipate in an online transaction supported by network 1260.Management of the data sets on transaction instrument 1240 may beperformed independent of the operation of the merchant system 1220(e.g., via issuer system 1230 or interaction device 1290). As such, thepresent invention may require no retrofitting of the merchant system1220, to accommodate system 1200 operation. Thus, where the merchantsystem 1220 is not configured to modify the data on the transactioninstrument, such modifications may be made as described above withrespect to modifications being made at the interaction device 1290 or bythe issuer at the issuer 1230 system.

The merchant system 1220, kiosk 1270, interaction device 1290, mayinclude additional means for permitting the transaction instrument user1201 to self-manage the data stored on the transaction instrument 1240.In this case, the systems 1220, 1270, and 1290 may include an additionaluser interface for use by the user 1201 to identify the modificationaction to be taken. Where the systems 1220, 1270, and 1290 areconfigured to communicate with the instrument 1240 and to modify thedata thereon, the modifications may be completed or substantiallycompleted in real-time or substantially real-time. For example, the user1201 may present the transaction instrument 1240 to one of the systems1220, 1270, or 1290, provide instructions to the system 1220, 1270, or1290 for modifying the data on instrument 1240. The instructions mayinclude, for example, “ADD,” “DELETE,” “MODIFY,” and the system 1220,1270, or 1290 may modify the data stored on the instrument 1240 inaccordance therewith. The modifications may be made on the instrument inreal-time or substantially real-time, for example, prior to permittingthe instrument 1240 to be used by the user 1201. Alternatively, themodifications or instructions for modification may be provided by theuser 1201 to the merchant system 1220 or kiosk 1270, and the merchantsystem 1220 or kiosk 1270 may further provide themodifications/instructions to the network 1260 for use in latermodifying the data. For example, the modifications/instructions may beprovided by system 1220 or 1270 to the issuer system 1230 managed by theissuer owning the data to be modified. The issuer system 1230 mayprovide the modifications to, for example, interaction device 1290, forupdating the transaction instrument 1240 when next presented. Themodifications/instructions may additionally be provided from the network1260 to a remote database, where the issuer-owned data corresponding tothe transaction device and the issuer may be additionally stored (i.e.,database 1282, described below). In one exemplary embodiment, themodifications/instructions may be stored at the issuer system 1230,until such time as the transaction instrument 1240 is next presented toa device configured to modify the data on the instrument. Oncepresented, the modifications/instructions may be provided to the device(e.g., computer 1250, interaction device 1290, etc.) for modifying theinstrument 1240 data.

In another exemplary embodiment, the user 1201 may self-manage the datasets by, for example, modifying the data sets using a conventionalcomputer system 1250, which may be in communication with the network1260. Computer system 1250 may or may not be configured to interact withfinancial transaction instrument 1240. Where the computer system 1250 isnot configured to interact with the transaction instrument 1240, theuser 1201 may provide modifications or instructions to the issuer system1230 for later use in modifying the corresponding transaction instrument1240 data, for example, when the instrument 1240 is next presented insimilar manner as described above. Where the computer 1250 is configuredto interact with the financial instrument 1240 to modify the data storedthereon, the user 1201 may provide modifications/instructions to thecomputer 1250 for modifying the data on the financial instrument inreal-time or substantially real-time. That is, the computer 1250 may beconfigured to interact with, read, add, delete, and/or modify the datasets on the instrument 1240. Consequently, the computer 1250 may receivemodifications/instructions from the user 1201 and perform themodifications accordingly, and may modify the data in real-time orsubstantially real-time. The computer 1250 may additionally beconfigured to receive authorization of the modifications/instructionsfrom issuer system 1230 prior to making the user 1201 requested changes.In one exemplary arrangement, the user 1201 may provide themodifications/instructions via the network 1260 which may beadditionally provided to the issuer system 1230. The issuer system 1230may receive the user 1201 modifications/instructions and verify whetherthe identified updates are available to the user 1201 or if theidentified updates are valid. If the identified updates are authorized,the issuer system 1230 may update a data storage area associated withthe transaction instrument 1240. For example, the issuer system 1230 mayupdate an issuer database (not shown) containing data corresponding tothe issuer-owned data associated with the transaction instrument 1240.Alternatively, the issuer system 1230 may providemodifications/instructions to a database positioned remotely to theissuer system 1230 for use in modifying the data stored thereon, whichis associated to the transaction instrument 1230. As such, in accordancewith the present invention, a user 1201 may self-manage the data via,for example, the user computer 1250, a kiosk 1270, a merchant system1220, and/or a stand alone interaction device 1290.

In one exemplary method of self-management, a user 1201 logs onto awebsite via user computer 1250, or onto a stand alone device, such as,for example, interaction device 1290 or kiosk 1270, and selects optionsfor configuring data sets on a financial transaction instrument 1240.The changes may be transmitted to the instrument 1240 via a instrumentreader/writer device 1280 configured to communicate the data toinstrument 1240. In this context, the reader/writer device 1280 may beany conventional transaction device reader or writer.

As noted, modifications to the data stored on the financial transactioninstrument 1240 may be made in real-time or substantially real-time whenthe instrument 1240 is presented to the interaction device 1290, or to areader/writer device 1280. However, as noted, various embodiments of theinvention include a remote database 1282 in communication with an issuersystem 1230 via a network 1260. The remote database 1282 mayadditionally be in communication with one of the user computer 1250,kiosk 1270, merchant system 1220 and/or the interaction device 1290, forvariously receiving modifications or instructions for performingmodifications to the data stored thereon. In addition, database 1282 maycontain a data storage area which “mirrors” the data stored ontransaction instrument 1240. In this context “mirrored” or “mirror” maymean that the data is stored on database 1282 in substantially identicalconfiguration and format as stored on the transaction instrument 1240.As such, the present invention may be configured to permit modificationsmade to instrument 1240 data to be mimicked on corresponding datalocations on database 1282. For example, the user 1201 may self-managethe data on the database 1282 via a user interface in communication withthe database 1282 via the network 1260. In one exemplary embodiment, theuser 1201 may communicate with a “website” which is used to manage thedatabase 1282, wherein database 1282 is a database including uniquelocations for storing the issuer provided data and data sets correlativeto the data and data sets stored on the transaction instrument 1240. Thewebsite may include an account management application which permits theuser 1201 to select which user accounts to add, delete, or modify withrespect to the instrument 1240. That is, the user 1201 may provideunique identifying information to the user computer 1250 which may berecognized by the system (e.g., issuer system 1230 or remote systemmanaging the database 1282) managing database 1282, thereby permittingthe user 1201 to access the data corresponding to the unique identifyinginformation stored on database 1282. Further, prior to permittingmodifications to the database 1282, the issuer owning the data mayrequire authorization that such modifications may be performed. Furtherstill, the present invention contemplates that database 1282 may beself-managed by the user 1201 in similar manner, where the merchantsystem 1220, kiosk 1270 and/or interaction device 1290 are configured toprovide modifications/instructions to the issuer systems 1230 anddatabase 1282.

In another exemplary embodiment, database 1282 serves as a temporary orredundant storage space for data sets. Thus, a “mirror image” of thedata sets currently on the financial transaction instrument 1240 may bemaintained and/or updated at appropriate intervals for facilitatingreplacement of, for example, a damaged financial transaction instrument1240. As such, database 1282 may be used, for example, for verifying thevalidity or accuracy of the information stored on the instrument 1240.Also, changes to one or more data sets may be stored to database 1282pending an opportunity to update the financial transaction instrument1240. In various embodiments, such updating may take place in bothdirections similar to hot sync technology.

As noted, in some exemplary embodiments of the invention, authorizationmust be obtained from issuer systems 1230 prior to making anymodifications to the data contained on instrument 1240 or database 1282.Authorization may be obtained by requesting the authorization during themodification process. Authorization may be given where the user 1201provides the more appropriate security information, which is verified bythe issuer system 1230. The security information may be, for example, asecurity code granting access to the issuer-owned data on the instrument1240 or database 1282. For example, a point-of-sale (POS) machine may beconfigured to allow the input of a code, or an answer to a prompt whichis provided to and verified by issuer system 1230. Once verified themodification requested may be made to the data contained on thefinancial transaction instrument 1240.

It should be noted that the authorization code may be used to permit theuser 1201 to select which issuer provided data to utilize for completionof a transaction. For example, a Point of Interaction Device (POI)device may be programmed to search the financial transaction instrument1240 for a data set containing a particular club membership data set, orto locate all available data sets for providing to a user 1201 displayavailable data sets to the user 1201, thereby permitting the user 1201to select which data set to use to complete a transaction. If no dataset is found, the POI device may alert the user 1201 or prompt themerchant to alert the user 1201 of the possibility of addingissuer-owned data to the financial transaction instrument 1240. Apositive response to this alert may cause the POI device to add anissuer data set to the instrument 1240.

It is noted that the user 1201 may already be a member of a membershipprogram managed by an issuer system 1230 in which case the associateduser 1201 membership data may be assigned to user 1201 for inclusion oninstrument 1240. As such, the user 1201 may be permitted to add themembership data set to the transaction instrument 1240. Alternatively,the user may become a member by selecting to add the membershipinformation to the financial transaction instrument 1240, using theinteractive device 1290. In some embodiments, changes made to the datasets stored on the transaction instrument 1240 may be updated to thefinancial transaction instrument 1240 in real-time or substantiallyreal-time, where the device 1290 is in communication with the instrument1240. Or the changes may be made the next time the user 1201 presentsthe financial transaction instrument 1240 to stand alone interactiondevice 1290 or to a kiosk 1270, merchant system 1220, or the like.

In another exemplary embodiment of the present invention, merchantsystem 1220, kiosk 1270, and/or user computer 1250 may be configured tointeract with financial transaction instrument 1240 via a read/writedevice 1280. Read/write device 1280 may be any device configured tocommunicate with financial transaction 1240. In one embodiment,read/write device 1280 is configured to read and write to financialtransaction instrument 1240. For example, read/write device 1280 may bea point of interaction magnetic card reader/writer. In another example,where the transaction instrument 1240 includes a RF transmitter/receiverfor communicating with system 1200, read/write device 1280 may include amating transponder configured to receive and transmit issuer-owned data.Read/write device 1280 may be configured to select data sets for use bya merchant using any suitable selection technique including but notlimited to proprietary commands or command sequences or use of ISO/IEC17816-4 application selection sequences (e.g., GET command).

In one exemplary embodiment, management of data sets is facilitated byannotating the data set with a status indicator (e.g., conditionheader); (e.g., LOADED, INITIALIZED, READY, BLOCKED, REMOVABLE orDELETED).

In this regard, a data set may have a LOADED status when the informationrelated to that data set has been stored in association with thefinancial transaction instrument 1240, but remains dormant. For example,a credit card account may have been added to the financial transactioninstrument 1240 that has not yet been activated. In some instances, theloaded data set needs to be further configured before it is ready to beused. For example, the data set may be modified to include a particularbranch in a chain of franchise stores, the identification of a user's1201 primary care physician, or to reflect a user's 1201 selection of aplatinum membership status. In another example, a loyalty program may beadded in association with a financial transaction instrument 1240, andthe data set marked LOADED. In another example, the user 1201 mayinteract with a kiosk 1270 or the like to input personal information andconfigure the loyalty program data set. Once such a data set has beenconfigured, it may be annotated with an INITIALIZED status.

The status of a data set may be set as READY when the data set is readyto be utilized. For example, a user 1201 may enter a secret code toindicate that the user 1201 is ready to use the data set. In oneexample, the data set may be marked as READY when that data set is firstaccessed to perform a transaction. It will be noted that in accordancewith other embodiments of the present invention, the status of a dataset may be set at READY the moment it is loaded to the financialtransaction instrument 1240. Furthermore, it is possible to change thestatus between READY, LOADED, and INITIALIZED, under appropriatecircumstances. Thus, the data sets may be managed through any one ormore of these states and in various orders.

It may also be desirable to prevent use of a data set and/or theassociated functionality for a period of time. Thus, the statusindicator may be set to BLOCKED. The setting of the status indicator toBLOCKED may, for example, disable the use of the data set. In oneexemplary embodiment, an appropriately configured financial transactioninstrument reader is configured to recognize the BLOCKED statusindicator when accessing the data set and to prevent use of that dataset example.

In addition, for various reasons, a user 1201 may desire to remove adata set from a transaction card 1240. The user 1201 may, for example,desire to use the available space on the transaction card 1240 for otherdata sets, or may remove the data set for security reasons. Furthermore,circumstances may arise where the owner of the data set desires toremove the data set from one or more transaction devices 1240, such aswhen a coupon expires. In these instances, the data set may be marked asREMOVABLE. Under these circumstances, the memory associated with thedata set is available to receive information associated with futureadded data sets, but for the moment retains the old data set. AREMOVABLE data set may again be made READY under various configurations.

The REMOVABLE data set may subsequently be removed from the financialtransaction instrument 1240 and marked DELETED. A DELETED statusindicator may be used to indicate that a portion of the financialtransaction instrument 1240 is available to store one or more data sets.It is noted that data sets may be directly deleted without going throughthe step of making the data set REMOVABLE. In one example, a data setmay be removed from the financial transaction instrument 1240 if thesecurity of the account associated with the data set is compromised(e.g., stolen password). Furthermore, as appropriate, the status of datasets may be changed to different states. Under appropriate circumstancesone or more of any of the six status indicators LOADED, INITIALIZED,READY, BLOCKED, REMOVABLE, or DELETED or other suitable statusindicators may be used to annotate a BLOB or other similar data set.

Although the data sets described herein may be managed without statusindicators, nevertheless, such status indicators facilitate managementof data. For example, regardless of a first data set owner's ability tointerpret the information stored in a data set owned by another party,the first owner may interpret the status indicator to determine whetherthe data set is LOADED, DELETED, or the like. The determination that adata set is DELETED facilitates the addition of new data sets byindependent owners without overwriting other data sets on the financialtransaction instrument 1240. In addition, the use of tags or statusindicators may facilitate the use of global rules, which may simplifyoperations and/or commands. Status indicators may also enhanceinteroperability between data sets. Nevertheless, a data set owner maychose not to use a status indicator even if the opportunity isavailable.

Managing of the data sets (step 1120) may include one or more of thefollowing exemplary steps: add, update, modify, replace, verify, deleteand/or the like. More particularly, FIG. 8 illustrates a generaloverview of an exemplary data set management method 1300 comprising thesteps of: loading a data set (step 1310), initializing a data set (step1320), verifying availability of data set (step 1330), and deleting adata set (step 1340). In this manner, a data set may be added to afinancial transaction instrument 1240 and utilized until it is deleted.The adding and deleting steps are described in further detail withreference to FIGS. 9 and 10. Furthermore, the ability to update, modify,replace and/or delete a data set may be subject to securityrequirements.

In one embodiment, the various processes may include a user 1201facilitating the input of information into a data management system tocause the data set to be loaded. The information may be inputted viakeypad, magnetic stripe, smart card, electronic pointer, touchpad and/orthe like, into a user computer 1250, POS terminal, kiosk 1270, ATMterminal and/or directly into the merchant system 1220 via a similarterminal or computer associated with merchant server 1222. Theinformation may be transmitted via any network 1260 discussed herein tomerchant system 1220 or issuer systems 1230. In another embodiment, themerchant may enter the information into an issuer system 1230 on behalfto the user 1201. This may occur, for example, when the user 1201 and/orissuer system 1230 authorizes the management of data sets on financialtransaction instrument 1240 over a telephone and the servicerepresentative inputs the information. In this embodiment, thetransaction instrument 1240 may be updated at the next presentmentopportunity such as when the user 1201 attempts to compete a transactionusing the transaction instrument 1240.

Any suitable procedures may be utilized to determine whether a data setis currently ready for use and available (step 1330). In one example,when a financial transaction instrument 1240 is presented, theavailability of the data set is verified by checking whether the dataset has been corrupted or blocked (step 1332), or deleted (step 1333).For example, the data set may be checked to determine if the data sethas been accessed or altered without permission (“corrupted”) or if thedata set exists or has been removed from the transaction device 1240(“deleted”). The check may be performed using any suitable protocol orcomparing data. If the answer to these questions is no, then the dataset is available and ready for use (step 1334). If the data is corruptedor blocked, subroutines may be used to attempt to retry reading the data(step 1336). If the data set is marked deleted or removable, subroutineswill prevent access to the data set (step 1335) and remove the data set(step 1340). For example, a suitable subroutine may place a DELETE“marker” on the data set which prevents the data from being transmittedduring completion of a transaction. The data set may then be marked fordeletion and deleted from the transaction device 1240 at the nextpresentment of the device. In similar manner, where the data set iscorrupted, a CORRUPTED marker may be appended to the data set and thedata set is prevented from being transmitted during completion of atransaction. The marker may be a header or trailer as discussed herein.

Various methods may be used to add a data set to a financial transactioninstrument 1240 or to replace a data set on a financial transactioninstrument 1240. FIG. 9 illustrates an exemplary method of adding a dataset to a financial transaction instrument 1240, including the generalsteps of presenting the financial transaction instrument (step 1410),verifying the addition of the data set to the financial transactioninstrument (step 1420), placing th data set in a temporary holding area(step 1430), and adding the data set (step 1440).

More particularly, the user 1201 presents the financial transactioninstrument (step 1410) to a device 1280 configured to communicate withinstrument 1240. The user 1201 may present financial transactioninstrument 1240 at a point of purchase or to an interaction device 1240or kiosk 1270. For example, the user 1201 may wave the RF transactiondevice 1240 in front of a POI machine in a retail store, which isconfigured to receive data from the device 1240. Alternatively, the user1201 may present the financial transaction instrument 1240 at aself-service location such as a kiosk 1270 in a mall. Moreover, the user1201 may present the financial transaction instrument 1240 to aperipheral device associated with a personal computer, or the like.

The user 1201 is then given the opportunity to add a data set to thetransaction instrument 1240. For example, device 1280 may detect theabsence of a particular data set on the transaction instrument bysearching the transaction instrument 1240 data base and comparing theexisting data sets to the data set to be added. If the data set to beadded is not found on the data base, the user 1201 may be prompted toconfirm the addition of this data set to the instrument (step 1420). Theuser may be prompted via an interactive user interface displaying theoption to add the data set. In one example, when a user 1201 presents afinancial transaction instrument 1240 to a merchant, the card readerdetects the absence of a loyalty data set and provides a message on adisplay to the user 1201 or the store clerk indicating that the loyaltydata set can be added if desired. The user 1201 may answer in thenegative and complete the purchase using typical transaction methods(step 1425). Alternatively, if user 1201 provides an affirmativeresponse, the algorithm may prepare a data set for communication withthe financial transaction instrument 1240 (step 1430). The process maydetermine whether the data set (or information that could be used tocreate the data set) exists in some form or on some device other than onthe financial transaction instrument 1240 (step 1432). Determiningwhether a data set exists may involve querying an issuer system 1230,database 1282, or the like. For example, the issuer system 1230 maycompare the data set to other data sets the issuer system 1230 hasassigned to a particular user 1201. If the data set is not assigned to aparticular user, then issuer system may determine that the data set isavailable for adding to the transaction instrument 1240. Determiningwhether a data set exists may also take place when a store clerkverbally asks (or a screen prompts) the user 1201 to present anothercard containing the information. For example, the data set may exist ona movie rental card and stored in magnetic stripe form, bar code, and/orthe like.

If the data set exists in an accessible form, the data set may becaptured (step 1436). In this example, the user 1201 may present themovie rental card and the data read from the movie rental card may thenbe stored in a data set associated with the financial transactioninstrument 1240. For example, the user 1201 may desire to add a shoppingloyalty card to the user's 1201 financial transaction instrument 1240.The user 1201 may swipe, scan or otherwise present the loyalty card suchthat the data set from the loyalty card is captured. The system may befurther configured such that the merchant, kiosk 1270, or computersystem may access an issuer system 1230 to obtain information forcreating the data set. Thus, if a user 1201 does not have the movierental card on the user's 1201 person, the system 1230 may prompt theclerk to request identifying/security information and to access theuser's 1201 account and therefore facilitate adding a movie rental dataset associated with the user's 1201 transaction instrument 1240. Anyother suitable methods of capturing data sets may also be used.

If the data set does not exist, a new data set may be created (step1434) for inclusion on the transaction instrument 1240. Creation of thedata set may, for example, involve filling out an application, providingname and address, creating an account, and/or the like. In either event,the pre-existing or newly created data set is temporarily held in astorage area (e.g., database 1282, local memory or the like) fortransfer to the transaction instrument 1240 (step 1438). Additional datasets may be prepared for transmittal to transaction instrument 1240(step 1439).

In this exemplary embodiment, the transaction instrument 1240 ispresented again to read/write device 1280 (step 1442). Read/write device1280 is configured to attempt to transfer the data set(s) to thetransaction instrument 1240 (step 1444). For example, existingread/write device 1280 may be configured with software and/or hardwareupgrades to transmit data to the transaction instrument 1240. In oneexemplary embodiment, if the data sets were not transferred correctly,the process may try the transfer again. In another exemplary embodiment,data sets are added one at a time or altogether. Thus, a user 1201 maypass a card through a card reader/writer one or more times during theaddition process. The transaction may be completed (step 1425) using thenew data set or another selected method of payment. The same steps maybe used in a self-service embodiment, however, in one embodiment, nofinancial transaction takes place along with the addition of data sets.It should also be noted that under appropriate circumstances, a user1201 could add data sets at a point of purchase without actuallycompleting a purchase.

In various exemplary embodiments, the user 1201 and/or the owner of thedata set may manage the data set (i.e., steps 1432-439) in advance ofpresenting the transaction instrument 1240. For example, a user 1201 onuser computer 1250 may choose to add or delete data sets via a websiteconfigured for management of data sets. In another example, an issuersystem 1230 may add functionality to an account and may desire to updatethe data set associated with that account. In either example, data setsthat have been prepared in advance, may be ready for transmission uponpresentment of the transaction instrument 1240. The transmission of thedata sets may be transparent to the user 1201. For example, the user1201 may present the transaction instrument 1240 (step 1442) to completea purchase and the waiting data sets may automatically be added to theuser's 1201 card (step 1440).

Similar steps may be taken to replace or update data sets with newinformation. For example, a user 1201 at a point of interaction may beinformed of an upgrade in functionality associated with an account orother data set. Following similar steps as discussed with reference toFIG. 9, the existing data set on the transaction instrument 1240 isreplaced with a new data set. Moreover, depending on permission rightsand/or hierarchies in place, if any, an existing data set may bereplaced with an unrelated data set. Other methods of adding andreplacing data sets may also be used to manage data sets on atransaction instrument 1240.

Furthermore, data sets may be deleted using any suitable techniques. Forexample, FIG. 10 illustrates an exemplary data set deletion method 1500.The user 1201 presents transaction instrument 1240 at a point ofpurchase, self-service location, or the like (step 1510). The POS devicemay be configured to facilitate the user 1201 providing input regardingdeletion of a data set (step 1520). For example, the POS device may askthe user 1201, via a test screen, whether the user 1201 desires tomanage the data sets on the transaction instrument 1240. Through aseries of menus and/or questions, the user 1201 may identify data setsthat the user 1201 desires to delete.

Furthermore, the POS device may be configured to interrogate a database1282 or specific issuer systems 1230 to determine whether the deletionof a data set has been requested earlier. If the user 1201 requestsdeletion of one or more data sets, the data sets are then identified(step 1530). It will be noted that step 1530 may occur concurrently withstep 1520 or the user 1201 may request deletion of a specific account atthis step. In other embodiments, accounts may be deleted per predefinedrules or policies, and/or the like. Upon presenting the transactioninstrument 1240 again, the identified data set(s) are removed from thetransaction instrument 1240 (steps 1540 and 1550). Other methods ofdeleting data sets may also be used to manage data sets on a transactioninstrument 1240.

In an exemplary embodiment, management of the data sets may furtherinclude selecting preferences for use of the data sets. For example, auser 1201 may indicate a desire to use data set A, associated with a lowinterest rate credit card, as a first option, but to use data set B,associated with a higher interest rate credit card when data set A isnot available. In another example, one data set may be used forpurchases of gas while another data set may be used for purchasingtravel tickets. The consumer data set preferences may be stored on thetransaction instrument 1240 as a data set. In this example, when thecard is presented, all available data sets are read and the card readerdevice determines which data sets are to be used based in part on thepreferences stored on the card, which preferences may be updated fromtime to time.

In one exemplary embodiment of the present invention, transactioninstrument 1240 is a RF device configured to transmit and receiveinformation via RF frequency. The RF instrument 1240 may be embodied inany form factor allowing presentment of the instrument 1240 for payment.Typical form factors may include a watch, card, FOB, or the like. Forease in understanding, the RF transaction instrument may be referred to,herein, as a “FOB.”

The FOB may be configured to communicate via a radio frequencytransponder to the merchant systems or account systems. In yet anotherembodiment, the FOB may be configured to comprise two or more antennaethat are both configured to send and receive information and the FOB maybe responsive to different RF frequencies. In this exemplary embodiment,each antenna may be configured to communicate using a particularprotocol and/or frequency. Thus, the FOB may be configured tocommunicate with two or more interaction devices 1280 that eachcommunicate with the FOB using different transmission frequencies. Formore information on dual antenna FOBs, see U.S. patent application Ser.No. 10/192,488, filed Jul. 19, 2002, by inventors Michael J. Berardi, etal., and entitled “System and Method for Payment Using Radio FrequencyIdentification in Contact and Contactless Transactions” and its progeny,which are hereby incorporated by reference.

As noted, the data associated with the transaction instrument 1240 maybe modified by the user 1201 and/or by the issuer system 1230. FIGS. 11and 12 respectively, depict exemplary methods for user 1201 and issuersystem 1230 data management. For example, with respect to user 1201self-management, the issuer system 1230 may provide the user 1201 with atransaction instrument 1240 (step 1602). The instrument 1240 may beprovided with pre-stored issuer-owned data, or the instrument 1240 maybe configured to permit the user 1201 to add the data at a later date.The user 1201 may the present the transaction instrument 1240 toread/write device 1280 for initiating the self-management process (step1604). The read/write device 1280 may then read the data on thetransaction instrument 1240, and provide the data to an interactiondevice 1290 for displaying to the user 1201 (step 1606). Alternatively,the interaction device 1290 may provide the user 1201 a list ofavailable data to be added to the instrument 1240.

The user 1201 may then be permitted to identify which data the user 1201wishes to modify (step 1608). Identification of the data may includeproviding the data with a trailer or header indicating the action to betaken (e.g., add, delete, augment, overwrite, etc.). The header and anindicator of the data to be modified may then be provided to the issuersystem 1230 (step 1610) for verification as to whether such desiredmodifications are available to the user 1201 (step 1612). If the desiredmodifications are not available, the modifications will not be made andthe user 1201 is notified accordingly (step 1614). The user 1201 maythen be permitted to identify whether other data is to be modified (step1616). If so (step 1608), the interaction device 1290 may provide arequest for modification to the issuer system 1203 (step 1610) and theverification process is repeated.

Alternatively, where the issuer system 1230 verifies that themodifications may be made (step 1612), the interaction device 1290 maymake the modifications to the appropriate data on the transactioninstrument 1240 (step 1618). Additionally, where the system 1200includes a remote database 1282 for storing a mirror image of the datacontained on transaction instrument 1240 (step 1620), the interactiondevice 1290, or issuer system 1230, may facilitate modification of theremote database 1282 (step 1622). The user 1201 may then be permitted toselect other data sets to modify (step 1616), in similar manner as wasdescribed above.

In either case, where the modifications are complete, the user 1201 maythen present the transaction instrument 1240 to a merchant for use incompleting a transaction.

FIG. 12 depicts an exemplary method wherein the issuer system 1230manages the data contained on the transaction instrument 1240. Forexample, the issuer may identify on the issuer system 1230 which datasets are to be modified (step 1702). The modifications may then be madeto the corresponding data set stored on the issuer system 1230 (step1706). Where the system 1200 includes a remote database 1282, the issuersystem 1230 may provide the modifications/instructions to the database1282 for updating the database 1282 accordingly (step 1706).

In addition, the issuer system 1230 may query as to whether the issuersystem 1230 is in possession of the transaction instrument 1240 formaking the modifications to the data set on the instrument 1240 inreal-time or substantially real-time (step 1708). If so, themodifications are made accordingly (step 1710) and the instrument 1240may then be provided to the user 1201 for use in completing atransaction using the distinct data sets modified (step 1712).

Where the issuer system 1230 is not in possession of the transactioninstrument 1240 at the time the issuer determines that modifications tothe data on the instrument 1240 are to be made (step 1708), themodifications may be made on the issuer system 1230 (step 1704), and maybe placed in queue, for uploading to the transaction instrument 1240when it is next presented to the issuer system 1230 or to an appropriateread/write device 1280 (step 1714). When the transaction instrument 1240is presented thusly (step 1716), the issuer system 1230 may be notifiedthat the transaction instrument 1240 is available for modifying, and theissuer system 1230 may then provide the instructions for modification(e.g., modified data including headers) to the appropriate read/writedevice 1280 for modifying the transaction instrument 1240 (step 1718).The transaction instrument 1240 may then be provided to the user 1201for use in completing a transaction (step 1712).

As noted, the transaction instrument 1240 may include multiple data setswhich correspond to distinct issuer systems 1230, and which may be usedto complete a transaction. The user 1201 may be permitted to choosewhich data set to use for transaction completion. FIG. 13 illustrates anexemplary method by which the user 1201 may choose which of the datasets to use to complete a transaction. For example, the user 1201 maypresent the instrument 1240 to a merchant system 1220 for use incompleting a transaction (step 1802). The merchant system 1220 may thenread the data stored on the transaction instrument 1240 and report tothe user 1201 all distinct data sets which may be used to complete atransaction (804). The user 1201 may then select the appropriate dataset (step 1806) and the transaction is completed accordingly (step1808).

It should be noted that completion of a transaction may be performedunder any business as usual standard employed by the merchant and/orissuer system 1230. For example, the merchant server 1222 may beconfigured to communicate transaction data to the appropriate issuersystem 1230, in real-time or substantially real-time, or by using batchprocessing at the end of each day. Any suitable means for delivering thetransaction data to the issuer systems 1230 may be used. In oneexemplary embodiment of the present invention, the transaction data maybe delivered to the issuer system 1230 via a network 1260. The issuersystem 1230 may receive the transaction information and process thetransaction under issuer defined protocol independent of any otherprotocol used by other issuers to process a transaction. The issuersystem 1230 may receive the transaction data and provide the merchantwith the appropriate satisfaction for the transaction.

It should be appreciated that the particular implementations shown anddescribed herein are illustrative of the invention and its best mode andare not intended to otherwise limit the scope of the present inventionin any way. Indeed, for the sake of brevity, conventional datanetworking, application development and other functional aspects of thesystems (and components of the individual operating components of thesystems) may not be described in detail herein. It should be noted thatmany alternative or additional functional relationships or physicalconnections may be present in a practical data set management system.

As may be appreciated by one of ordinary skill in the art, the presentinvention may be embodied as a method, a data processing system, adevice for data processing, and/or a computer program product.Accordingly, the present invention may take the form of an entirelysoftware embodiment, an entirely hardware embodiment, or an embodimentcombining aspects of both software and hardware. Furthermore, thepresent invention may take the form of a computer program product on acomputer-readable storage medium having computer-readable program codemeans embodied in the storage medium. Any suitable computer-readablestorage medium may be utilized, including hard disks, CD-ROM, opticalstorage devices, magnetic storage devices, and/or the like.

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function specified in the flowchart block or blocks.The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer-implemented process such that theinstructions which execute on the computer or other programmableapparatus include steps for implementing the functions specified in theflowchart block or blocks.

It should be noted that although the present invention is discussed withrespect to Internet Service Providers, and systems and networks whichmay communicate via a leased line (T1, D3, TCP/IP etc.), the inventionis not so limited. The present invention contemplates conventionalprotocol, networks and systems which support a wide range of datatransfer. For example, in accordance with this invention, a transactionmay be completed using telephone lines connecting long distance carriersystems. In this instance, the issuer-owned data which may be includedon transaction instrument 1240 using any of the methods discussedherein, may be an account number which corresponds to long distancecalling time such as may be done with a conventional calling card.

Where the transaction instrument 1240 is loaded with several distinctdata sets, each corresponding to a distinct data set owner operating ondistinct and non-compatible communications network, the user of thetransaction instrument 1240 may use the instrument to complete longdistance calls on each of the distinct communications network,independently of the other. This is especially useful for a transactioninstrument 1240 user who may travel to different locations, where thedifferent locations support different long distance communicationsnetwork. In this exemplary embodiment, the present invention enables auser to anticipate which communications network is available in manydifferent travel destinations, and include the corresponding mating dataset on transaction instrument 1240 prior to beginning travel. In thisway, the transaction instrument 1240 user may be prepared to use thetransaction instrument 1240 as a long distance calling card irrespectiveof his anticipated travel destination.

It should be understood, however, that the detailed description andspecific examples, while indicating exemplary embodiments of the presentinvention, are given for purposes of illustration only and not oflimitation. Many changes and modifications within the scope of theinstant invention may be made without departing from the spirit thereof,and the invention includes all such modifications. The correspondingstructures, materials, acts, and equivalents of all elements in theclaims below are intended to include any structure, material, or actsfor performing the functions in combination with other claimed elementsas specifically claimed. The scope of the invention should be determinedby the appended claims and their legal equivalents, rather than by theexamples given above. For example, the steps recited in any methodclaims may be executed in any order and are not limited to the orderpresented in the claims. Moreover, no element is essential to thepractice of the invention unless specifically described herein as“critical” or “essential”.

1. A method for providing a multiple-service card, the method comprisingthe steps of: receiving at a service partner an application for amultiple-service card from a consumer, said application comprisingfields which include credit card application information for aparticular credit card and service partner information, said servicepartner information related at least in part to a private retailertransaction instrument associated with said service partner; extractingsaid service partner information from said application; communicatingsaid service partner information to said service partner to determine ifsaid service partner desires to provide access into an establishment ofsaid service partner and to allow purchase of goods and services fromsaid service partner using said particular credit card; extracting saidcredit card application information from said application for themultiple-service card; communicating said credit card applicationinformation to a provider of credit services, said provider of creditservices thereafter determining whether it desires to extend credit tothe consumer; if said provider of credit services desires to extendcredit to the consumer, establishing an account associated with saidconsumer, and sending the multiple-service card to the consumer, whereinsaid multiple-service card is configured for providing a primary party'sservices and a service partner's services, and transferring the accountto a second service partner, wherein said step of transferring comprisestransmitting a file comprising indicia of a service partner account. 2.The method of claim 1 further comprising replacing the multiple-servicecard, wherein said step of replacing comprises: a. requesting a cardreplacement administrator to create a replacement card; b. in responseto said step of requesting, said card replacement administratorcommunicating with a card service engine; c. said card service enginecommunicating account information to a card generator; d. said cardgenerator communicating the account information to the service partner;and e. said service partner communicating the account information to thecard replacement administrator.
 3. The method of claim 1 furthercomprising canceling a service partner private retailer transactioninstrument, wherein said step of canceling comprises: a. transmitting afile comprising indicia of an account to be canceled, b. producing acancellation report, and c. producing a balancing report.
 4. The methodof claim 1 further comprising canceling a primary party account, whereinsaid step of canceling comprises: a. transmitting a file comprisingindicia of an account to be canceled, b. producing a cancellationreport, and c. producing a balancing report.
 5. The method of claim 1,further comprising calculating and issuing a rebate on said credit card,wherein said rebate is based upon purchasing products and services atsaid service partner.
 6. The method of claim 1, further comprisingassigning a product control number to said application.
 7. Atransferable, multiple-service card associated with a service partner, aprimary party, and a holder, the card comprising: a first side and asecond side, the first side having first indicia associated with saidprimary party, the second side having second indicia associated withsaid service partner, wherein said multiple service card is obtained by:receiving at said service partner an application for themultiple-service card from a consumer, said application comprisingfields which include credit card application information for aparticular credit card and service partner information, said servicepartner information related at least in part to a private retailertransaction instrument associated with said service partner; extractingsaid service partner information from said application; communicatingsaid service partner information to said service partner to determine ifsaid service partner desires to provide access into an establishment ofsaid service partner and to allow purchase of goods and services fromsaid service partner using said particular credit card; extracting saidcredit card application information from said application for amultiple-service card; communicating said credit card applicationinformation to a provider of credit services, said provider of creditservices thereafter determining whether it desires to extend credit tothe consumer; if said provider of credit services desires to extendcredit to the consumer, establishing an account associated with saidconsumer, and sending the multiple-service card to the consumer, whereinsaid multiple-service card is configured for providing a primary party'sservices and a service partner's services; and transferring the accountto a second service partner by transmitting a file comprising indicia ofa service partner account.
 8. The multiple-service card of claim 7, saidfirst indicia including an account number, a name of the holder, and anexpiration date.
 9. The multiple-service card of claim 7, said secondindicia including a service partner information.
 10. Themultiple-service card of claim 7, said second indicia including at leastone of a magnetic stripe that accesses an account information, signatureblock, customer service number, private retailer transaction instrumentand an image of the card holder.
 11. A method for facilitatingmanagement of a plurality of data sets on a transaction instrument, themethod comprising the steps of: enrolling a first data set ownerassociated with an open transaction instrument and a second data setowner associated with a private retailer transaction instrument inmultiple transaction accounts on a transaction instrument program;adding to a database on the transaction instrument, a first data set ofa first format, before issuance of the transaction instrument by anissuer, wherein said first data set is owned by said first data setowner; adding to a database on the transaction instrument, a second dataset of a second format, after issuance of the transaction instrument,wherein said second data set is owned by said second data set owner,said first owner is distinct from said second owner, and said firstformat is different from said second format, said first data set isstored in accordance with said first format, and said second data set isstored in accordance with said second format; and modifying at least oneof said first and second data set in said database.
 12. A method ofclaim 11, wherein said database is a remote database remote from saidtransaction instrument.
 13. A method of claim 11, wherein said databaseis a radio frequency database.
 14. The method of claim 11, furthercomprising adding of a first condition header to at least one of saidfirst and second data sets, said header added independent of said firstor second format.
 15. The method of claim 14, further comprisingmodification of at least one of said first and second data sets inaccordance with said condition header.
 16. The method of claim 15,further comprising the step of deleting of said second data set inaccordance with said condition header.
 17. The method of claim 16,further comprising the steps of: updating of said first data set; anddeleting of said first data set from the transaction instrument.
 18. Themethod of claim 17, wherein said first data set is stored in a firstmemory area and wherein said first memory area is reusable by a thirddata set after said first data set is deleted from said first memoryarea.
 19. The method of claim 14, further comprising the step of addingof a third data set to the transaction instrument, wherein said thirddata set is stored, at least partially, in at least a portion of a datastorage space that was used to store said second data set.
 20. Themethod of claim 11 further comprising adding, by an interaction device,of a third data set of a third format to the transaction instrument,wherein said third data set is owned by said first owner.
 21. The methodof claim 11, wherein said first and second data sets are each stored asa block of binary.
 22. The method of claim 21, wherein each of saidfirst and second blocks of binary are annotated with at least one statusindicator for indicating an action to be taken with the blocks ofbinary.
 23. The method of claim 22, wherein said updating and saiddeleting of said first data set is accomplished without involving anissuer of the transaction instrument and is independent of any otherdata set owner.
 24. A system for facilitating management of a pluralityof data sets stored on a radio frequency transaction instrument, saidtransaction instrument comprising: at least one data storage areaconfigured to store a first data set in a first format and a second datastorage area configured to store a second data set in a second formatdifferent from said first format, said first data set associated with afirst owner, wherein said first owner is associated with an opentransaction instrument and said data storage area configured to storesaid first data set in said first format independent of said second dataset, and, said second data set associated with a second owner, whereinsaid second owner is associated with a private retailer transactioninstrument and said data storage area configured to store said seconddata set in said second format independent of said first data set; aremote database configured to store a duplicate of information in saidfirst data storage area and said second data storage area; and aninteraction device configured to read and write data to said transactiondevice storage area, said interaction device configured to receive saidfirst and second data sets from said remote data base, and to providesaid first and second data sets to said transaction instrument database, wherein at least one of said first and second data sets stored insaid remote database is annotated with a condition header.
 25. Thesystem of claim 24 wherein at least one of said first and second datasets in said remote database is modified in accordance with saidcondition header.
 26. The system of claim 24 wherein at least one ofsaid first and second data sets in said RF transaction database ismodified in accordance with said condition header.
 27. The transactioninstrument of claim 24, wherein said condition header identifies atleast one of the following status conditions: loaded, initialized,ready, blocked, removable, and deleted.
 28. The transaction instrumentof claim 24, further comprising a first data storage area, wherein saidfirst data storage area is configured to receive data of any format. 29.The transaction instrument of claim 24, wherein said transactioninstrument includes a radio frequency operable transponder.
 30. A datamanagement system comprising: a transaction instrument associated with afirst data set of a first format and a second data set of a secondformat, wherein said first data set is owned by a first owner associatedwith an open transaction instrument and said second data set is owned bya second owner different from the first owner and said second data setis associated with a private retailer transaction instrument, andwherein said transaction instrument is configured to facilitate at leastone of a first data set owner and a user of said transaction instrumentin managing said first data set without involvement of an issuer of saidtransaction instrument, and wherein at least one of said first andsecond data sets is annotated with a condition header; a databaseconfigured to store said first and second data sets, said first data sethaving a format different from said second format, said databaseconfigured to store said first data set in accordance with said firstformat, and said database configured to store said second data set inaccordance with said second format; and an interaction device configuredto communicate with said transaction instrument and said database, saidinteraction device configured to receive said first and second data setsand to provide said first and second data to said transactioninstrument.
 31. The system of claim 30, wherein said first and seconddata sets are managed via a self-service user interaction device. 32.The system of claim 30, wherein said interaction device is configured tomodify at least one of said first and second data sets according to atleast one of the following management actions: adding, updating, anddeleting said first data set.
 33. A method, comprising: receiving atransaction device application at a first service partner, wherein thetransaction device application comprises service partner applicationinformation and financial account application information; granting,based at least in part on the service partner application information,access rights into an establishment of the first service partner;communicating the financial account application information to afinancial services provider to facilitate approval by the financialservices provider of an account in response to the financial accountapplication information; providing a transaction device to a consumer,wherein the transaction device is configured for accessing services fromthe financial services provider and the first service partner; andreceiving a request to transfer the account to a second service partner;and facilitating the transfer to the second service partner in responseto the request to transfer.
 34. The method of claim 33, wherein thetransaction device is a radio frequency (RF) transaction device.
 35. Themethod of claim 33, further comprising configuring the transactiondevice to access services from at least one of the second servicepartner or a second financial services provider.
 36. The method of claim33, further comprising: adding a first data set of a first format to thetransaction device, wherein the first data set is owned by a firstissuer; and adding a second data set of a second format to thetransaction device, wherein the second data set is owned by a secondissuer.
 37. The method of claim 36, wherein the first issuer is thefirst service partner and the second issuer is the financial servicesprovider.
 38. The method of claim 36, wherein the first format isdifferent than the second format.
 39. The method of claim 36, furthercomprising adding a condition header to at least one of the first dataset or the second data set, wherein the condition header is independentof the first or second format.
 40. The method of claim 39, furthercomprising modifying at least one of the first data set or the seconddata set, in accordance with the condition header.
 41. The method ofclaim 39, further comprising deleting the second data set in accordancewith the condition header.
 42. The method of claim 36, wherein the firstdata set is independently managed by the first issuer, and wherein thesecond data set is independently managed by the second issuer.
 43. Themethod of claim 33, further comprising creating a mirror image, on aremote server, of data stored on the transaction device.
 44. The methodof claim 43, further comprising updating the mirror image in response toverification of updated information, and in response to at least one ofissuer provided instructions, user provided instructions, or an issuerdefined data storage protocol.
 45. The method of claim 43, wherein themirror image data is data substantially identical in configuration andformat as the data stored on the transaction device.
 46. The method ofclaim 33, further comprising associating the account with a secondtransaction device, wherein the second transaction device is associatedwith the second service partner.
 47. A method, comprising: receiving, ata financial services provider, financial account application informationfrom a first service partner in response to a transaction deviceapplication, wherein the transaction device application comprisesservice partner application information, and the financial accountapplication information; approving an account in response to thefinancial account application information; associating the account witha transaction device, wherein the transaction device is configured foraccessing services from the financial services provider and the firstservice partner; and facilitating a request to transfer the account to asecond service partner.
 48. The method of claim 47, wherein thetransaction device is a radio frequency (RF) transaction device.
 49. Themethod of claim 47, wherein the second service partner grants accessrights into an establishment of the second service partner based atleast in part on the service partner application information.